Мобильная игра - Пустошь №2
Забор, расширяющий сознание
Как известно, самое первое, что нужно сделать, когда пишешь код, — это продумать архитектуру программы, соблюдая все правила и рекомендации. Я поступил именно так, когда стал работать над игрой.
У меня опыта не много, поэтому я знал, что точно где-то совершу ошибку или изобрету велосипед. Но, как говорится, попытка не пытка. Я придумал, как реализовать карту в игре, все было отлично, все нормально писалось и работало.
И вот осталось совсем ничего: добавить финальные штрихи и довести до ума. Один из этих «штрихов» был забор. Он, как известно, состоит из колышка и стенки в направлении к другому забору. Звучит просто, но если перевести на язык кода, это означало, что состояние объекта зависит от объектов вокруг него. А с этим была проблема: придуманная архитектура не позволяла это сделать.
«Ну» — думаю я, — «Сейчас немного ее подкорректируем и готово». Но как бы не так. Оказалось, что проблема не просто в архитектуре, проблема в той парадигме, которую я использовал для написания кода. Пришлось не просто все переписывать, пришлось менять весь подход и думать другими категориями и объекта. Вот такой забор.
Программист в моей команде - Андрей Лукьянов
- 05 мая 2022, 17:36
Это... Блин... Как на этом сайте вставлять значок Якубовича?!
Открыть комменты какого-нибудь Эсдира и скопировать у него этот смайл :)
Интересно было бы почитать про то, что было, и к чему вместо этого пришли
Сначала архитектура была создана с обычной парадигмой ООП.
То есть, например, есть объект на карте, у него свои правила, свойства и т.п. Есть объект "Карта", которая соединяет между собой все эти объекты на карте. То есть, объект на карте знает только о себе, а объект "Карта" знает обо всем. Самая стандартная архитектура.
Но вот забор уникальный, ему для жизни нужно знать, какие заборы стоят рядом. И, казалось бы, можно просто написать функцию, которая обращается к карте и просит всю нужную информацию. Но такое решение очень плохое, потому что объекты "ниже" не должны знать о том, что происходит сверху, иначе нарушится модульность архитектуры и менять в ней что-то будет очень тяжело.
Поэтому я отправился в интернет для поиска вдохновения. И узнал, что в Unity (движок, на котором мы пишем), принята парадигма КОП. Честно, принципиальную разницу я пока понять не могу, но вдохновение я нашел.
Теперь существует "Мировой эфир". Это такой объект, к которому все объекты в игре могут отдать какое-то событие, которые с ними произошло. Например, из переместили. К этим события могут быть "наблюдатели", которые, проще говоря, просто реагирует на это событие. Мировой эфир передает таким объектам информацию о событии. И да, вы правильно поняли, все заборв наблюдают друг за другом.
Как-то всё очень абстрактно и без деталей: какая парадигма была, на какую изменилось, почему выбранная сначала одна, потом другая...
Да по-моему нормально всё описано. Вон, человек хотел сделать всё "красиво", а столкнулся с тем, что это - творческий труд, в котором вообще сложно заранее понять, что именно делаешь. Сделаешь одним образом - оно не работает (не в том плане, что не запускается, а в том - что не работает на идейном уровне.) Идёшь переписывать. Я одну штуку переписывал трижды, и скорее всего это не предел. Ну... По факту.
Когда добавляешь что-то, то думаешь: а могу ли я объединить объекты этого типа с объектами другого типа? Или мне следует всё же создать ещё один мусорный одноразовый скрипт для именно этого магазина с боеприпасами? Стоит ли мне писать более "абстрактный" код, с кучей настроек и лазеек для модификаций для единичного объекта, или лучше написать быстрый скрипт в две строки именно для этого случая? Надо сидеть, думать, что вообще может прийти тебе в голову, что может понадобиться... И какие проблемы влекут за собой каждое из этих решений. Главное не сокращать и не делать код оптимальным, всё равно это только прибавит работы.
Вот чем меньше всяческих конструкций и чем лаконичнее код - тем удобнее работать с ними дальше. А вот вносить в них изменения - сложно. Такой вот баланс удобства и широты возможностей. Да и игра ка бы становится понятней в своих принципах работы. У игры же должны быть явные правила. А если их не выделить, и каждый схожий объект описывать по новой, то и игра невнятной получится.
Твой комментарий не более информативен, чем текст поста. Автор уже ответил более детально в данном комментарии. Как видно из него, он рассказывает какие парадигмы применялись, почему они ему не подошли и что нашлось на замену и почему. Вот, что интересно читать: опыт других. А не запись в личном дневнике:
Вот такое мне кажется не информативным и бесполезным. Да, молодец, что старается делать по уму, но и рассказывать надо про как ты сделал то или иное, а не просто, что "хотел сделать по уму". К этому моя "претензия".
Блин, я думал щас зайду под кат и там будет скриншот "вот какой забор"
"ВооООООООт такой забор!"
*растягивает руки в стороны*