Еженедельный отчет о марафоне. Неделя 1

Начиная марафон с 18 мая,  я знал, что будет нелегко, т.к. на эту неделю уже были планы(3 дня были полностью заняты), и было понятно, что выделить даже 10 часов будет сложно. Но я считаю, что справился с этой задачей. Конечно, я начал нарушать правила еще до начала!

Итак. Я решил начать еще в прошлую субботу. Быстренько накидал в фотошопе отладочный арт открыл юнити. Здравствуй чистый лист! Начиная писать с нуля, всегда есть вопрос, с чего начать. Если в прошлый раз я пошел в лоб - надо научить клетки меняться местами, потом решим следующую задачу, то в этот раз я попытался поступить по другому. 

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

Так вот, в прошлый раз я пошел по пути "Заказчику нужна фича - надо сделать". Это привело к тому, что буквально за неделю код превратился в непонятный объемный набор операторов и костылей, которые тесно связаны между собой, при этом был огромный набор непонятных труднодиагностируемых ошибок. Такое в своих проектах допускать я больше не хочу - этого хватает на работе...

Для начала я решил, что у меня не будет никакого центрального элемента, который бы молотил все объекты, в том числе гравитацию(опускание столбцов вниз, после удаления трех ячеек). В прошлый раз гравитация была сильно тормознутой. Я решил поэкспериментировать и сделать "эфир", в который бы все ячейки сообщали, что с ними происходит, и исходя из этого принимали решение что-либо сделать. Отлично - паттерн Наблюдатель, считай классика, связь многие ко многим. За час был набросан прототип реализации под мою задачу в отдельном проекте в VS2010 на C#, потом была кружка кофе, и перенос в игровой проект. На первой же срочки MonoDev предложил оператор, который меня заинтересовал - BroadcastMessage. И тут меня осенило: я понял о чем писалось в какой-то статье, которую как-то читал на хабре, точнее понял как это можно применить.

Почитал доки, я сохранил свою реализацию наблюдателя на жестком, велосипеды мне пока не нужны. Суть BroadcastMessage в возможности рассылать сообщения ветви иерархии объектов. В моем случае это был родительный пустой объект GameCells, к которому привязываются "ячейки", а уже к ячейкам привязывается содержимое - спрайты с изображениями. Сейчас весь код находится в ячейке, а изображение и движение - в содержимом. При перемещении ячейки остаются на месте, а содержимое перепривязывается между ячейками.

Так вот, Broadcast посылает всем сообщение, а, по сути, вызывает метод класса для каждого дочернего объекта:

void OnMouseDown()
{
if (Item != null) {
Parent.BroadcastMessage ("msgSelectedCell", this);
}
}

Метод msgSelectCell обрабатывает всю логику выделения.

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

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

public int[,] Maps={

{1,2,3,2,1,3,1,3,0,3,1,2},

{2,1,2,3,3,2,1,2,2,3,1,2},

{1,3,0,0,0,3,2,3,3,1,2,3},

{1,2,3,2,1,3,1,3,1,3,1,2},

{2,1,2,3,3,2,1,2,2,3,1,2},

{1,3,3,2,2,3,2,3,3,1,2,3},

{1,2,3,2,1,3,1,3,1,3,1,2},

{2,1,2,3,3,2,1,2,2,3,1,2},

{1,3,3,2,2,3,2,3,3,1,2,3},

};

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

На BroadcastMessage была сделана гравитация. Эта реализация меня удовлетворила - работает  прозрачно и быстро. Если ячейка оказалась пустой, то она делает об этом "рассылку",  а все заинтересованные в этом ячейки перемещаются вниз.

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

Несмотря на то, что результаты вроде бы небольшие, я получил очень неплохой опыт в проектировании и реализации решения. Все полученные результаты анализировались и, надеюсь, в будущем еще на стадии схемы на бумаге, я буду видеть больше проблемных мест.

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

Итого, с учетом начала работ "авансом" и чтение статей, плюс обдумывание различный вариантов, я посвятил на этой неделе более 10 часов.