Комментарии 17
Я вам поставил плюсик, ибо старались написать и оформить статью, но, честно говоря, ничего особенного я не увидел - мы тут каждый день кодим и делаем примерно то же, что и вы в статье. Как читателю, мне было бы интересно почитать какие-то необычные случаи в разработке, какое-то подводные камни и так далее. Ну вы поняли :)
И да, с новым годом!
В прошлой статье вы писали
Но тут не только опытные профессионалы читают статьи - возможно, кто-то хочет сделать игру, но его отпугивает, что "программирование - это сложно". А тут наглядный пример, что это вообще не помеха.
По-моему, примером это было бы, если бы у вас уже была готовая игра, которую вы бы сделали без особых проблем. А пока это наглядный пример, как потратить много-много времени, сделать движущиеся квадратики и выгореть. Причём основная ваша проблема именно в недостатке знаний, потому что да, программирование - это сложно.
В общем, верно, да) немного спойлеров: тут описаны не все детали) глобально все то же самое, но часть кода раньше времени может анонсировать мое видение проекта, которое несколько отличается от референсного лабиринта из AFK arena
На самом деле, проблема есть ещё с планированием. За один присест выполнять три пункта из фичей - это как-то слишком. Очень желательно разнообразие задач и чредовать разные типы. Например, делать фичу - делать сервер - делать фичу - заняться аналитикой - ну и так далее
Вы молодец, что продолжаете работу, несмотря на сложности.
Примерно тут мне все начало слегка так надоедать. Код разрастается, понимаю я в нем все меньше и меньше. Для того, чтобы делать новые фишки, приходится перелопачивать старые. Усугубляется тем, что сейчас я не слишком следую плану.
Рано или поздно вы закончите эту игру и возьмётесь за что-то новое. Мне кажется, что вам очень поможет сделать паузу и улучшить свои навыки в архитектуре приложений и написании чистого кода.
Вот простой пример, вы пишите:
if (_battleStarterScript.ActiveEnemies.All(ActiveEnemies =>
ActiveEnemies.GetComponent<Characteristics>().IsDead))
Но будете ли вы через неделю помнить, что это обозначает? Не будет ли подспорьем переменная объясняющая всё это выражение? Например:
boolean allEnemiesDead = _battleStarterScript.ActiveEnemies.All(ActiveEnemies =>
ActiveEnemies.GetComponent<Characteristics>().IsDead))
if (allEnemiesDead) {...}
А это лишь песчинка на вершине айсберга вашего проекта. Перелопачивание и переписывание кода - это нормально. Однако это намного сложнее делать, если код написан "лишь бы оно работало". Работать-то может и будет, но внесение изменений в такую программу отнимает кучу времени и сил. В итоге всё это надоедает и вы проклинаете тот день, когда сели за баранку этого пылесоса.
И это - нормально! Мы все были там, где вы сейчас. Невозможно стать хорошим программистом без практики, без трудностей и кучи набитых шишек. Дерзайте, у вас всё получается!
Почему бы, например, вместо того, чтобы проверять по массиву, все ли убиты, не сделать счетчик и просто сравнивать с длиной массива?
Изначально хотел сделать, чтобы смерть противника просто увеличило какое-нибудь число в этом скрипте (что-то типа "int totalDead++"), и просто сравнивать if (totalDead >= ActiveEnemies.Count). Но чисто гипотетически возможна способность воскрешения. И, вроде бы, при этом можно делать так "totalDead--", но мне почему-то кажется, что тогда обязательно появятся баги. Но спасибо - нужно будет потестировать.
P.S. Сейчас подумал - хотя нет, я как-то иначе хотел сделать. Написанный сейчас вариант вроде как более чем рабочий
Присоединяюсь к комментатору выше. Автор, Вы молодец, что все же стремитесь закончить свой проект. Но обязательно прочитайте что нибудь по чистоте кода. Например, о том, что передавать больше 2-3 значений в метод крайне не рекомендуется. Очень сильно ухудшает читаемость. Тот же дядя Боб рекомендует в таких случаях, если не удается избежать их - создать структуру settings к примеру, и передавать аргументом 1 этот объект. А в сам объект можно более наглядно сеттить нужные вам аргументы. settings.StartLevel = 1;
Спасибо! Да, мне и самому не нравится передавать в метод больше одного (!) значения) всячески стараюсь такое избегать) Про структуру вроде понял - получится, вместо условного (int aa, int bb, ..) сделать условную (MyStruct numbers)
Хмм, про settings.StartLevel = 1; нужно подумать - примерно понял, что мне это даст, но надо продумать детали. Спасибо!)
Интересно наблюдать, как человек, абсолютно не умеющий писать код, пытается писать код. Вам очень повезло с навыком написания тестов и с навыком оправдания своих действий.
Если вы немного почитаете про объектно ориентированное программирование и принцип разделения ответственности, то поймёте, почему вам стало сложно работать с кодом.
Ваша основные проблемы - отсутствие навыка построения архитектуры и отсутствие опыта написания кода. Ваше огромное преимущество - наличие чуйки.
Мне очень интересно, во что превратится кодовая база проекта к концу эксперимента. Если сможете, пожалуйста, выложите в открытый репозиторий код проекта.
И я вас призываю не откладывать рефакторинг на потом - именно из-за отсутствия нормальной архитектуры вы страдаете последние три статьи.
Ахах, спасибо xD
Хмм, возможно, и выложу в открытый доступ. Только нужно будет перед этим подумать о безопасности игроков: и как и выложить код, и как сделать так, чтобы при этом никакие данные игроков при этом нельзя было получить + никак на эти данные повлиять. Пока не смотрел, как делается серверная часть - может, будет достаточно просто не публиковать то, что с ней связано
Пожалуй, воспользуюсь советом, пока не стало сильно поздно - спасибо!
сделать сюда кучу героев и деактивировать их. А потом в нужный момент просто активировать нужного
Вообще, это называется пул и ты правильно думал, но немного не довел эту идею до конца
Меня остановило то, что так уже сделано в скрипе Spawner)
На этот момент на сцене уже есть куча деактивированных героев и противников - и абсолютно все массивы в других скриптах, где используются герои, ссылаются именно к ним. Проблема с тем, чтобы как-то либо создать копию героя (причем нужен только визуал), либо имеющегося героя активировать и ставить в нужное место.
Подумал, что второй вариант - это как-то слишком. Зачем мне там нужен герой, который умеет находить противника, драться и все такое? Так что решил сделать что-то вроде визуального клона. Но, для того, чтобы не создавать еще кучу объектов, сделал всего один, которому и присваиваю нужный визуал. Пока что это просто спрайт, но и с анимацией проблем возникнуть не должно.
Хотя очень может быть, что я ошибаюсь и вообще делаю неправильно - наверняка есть способы и проще, и производительнее
Может попробуете что-нибудь пока несложное. Слишком масштабный проект для новичка.
Что ж. По какой-то причине не могу оставить коммент к 5-ой части.
Если кратко, стало понятно, что код для вас - это что-то типа уборщика на складе. Вроде как-то работает, вроде есть результат. Пока не уволился и не умер, норм.
Вы очень торопитесь. В коде много ошибок: в написании слов, в стилистике, в логике.
Попытка стать кодером с наскока - забавна.
Мы чётко видим результат. Кодить не просто, а кодить хорошо - сильно сложнее. Я уже не говорю про разработку в целом, тут вообще ад.
Спасибо, что разбиваете миф о простоте нашей профессии.
Опыт разработки первой игры на Unity, часть 4