Говорят, первой программой у каждого разработчика должен быть вывод «Hello, world» в консоль. С программой так было и у меня, в далеком 2007 году, когда я поступил в колледж на специальность "Автоматизация вычислительных систем" и писал я эту программу на Visual basic
// в конце статьи бонус
Ваша первая программа была такой же?
Ну а первой моей настоящей игрой стал мой RedGuy :D. Его я и хочу вам сегодня представить!
Когда я отучился в колледже — я сразу забросил программирование и до сего дня развивался совершенно в другую, но около IT специальность. Я бизнес-аналитик. Однако я постоянно чувствовал тягу к созданию своего ПО, своей игры, своего сайта и вот решил попробовать себя в том, что больше всего из этого увлекает.
Купил курс и начал клепать игры, ни одну не доделывал, просто обучался Unity и C#. А вот на этом платформере решил остановиться и попытаться реализовать всё что приходило в голову.
Какие механики я хотел реализовать?
стрельба
прыгать
- конечно же бегать
прыгучие поверхности, типа батута
- лазать по лестницам
- подбирать монетки и учитывать их в счёт игры
- убивать монстров и умирать от них
- иметь количество жизней, которое отнимается при смерти
- умирать от шипов или каких то еще препятствий
- сохранять состояние уровня при перезагрузке от смерти, но обновлять при окончании всех жизней
- переход с одного уровня на другой
- звуки музыка
Все ассеты я взял из обучающего курса, они являются бесплатными для некоммерческого использования. Звуки находил на бесплатных сервисах, подрезал (как цветочки) и изменял их (как своё отношение к биде)
Особенно горжусь своей работой над музыкой. Она зациклена до запуска игры и в момент запуска красиво переключается на другую мелодию
Энтузиазма у меня было хоть отбавляй и в целом весь проект пилился очень легко, однако были и вещи, который изрядно выбешивали:
Префабы
Пока я сообразил как они работают, как изменяются дочерние/родительские элементы и пока не привык применять изменения на дочке к родительскому префабу — постоянно ловил кучу косяков, чуть не поседел
Синглтоны
Это то, что я до сих пор не поборол. Реализовал у себя, дебажил 10 часов и достиг нужного эффекта, но в голове всё равно каша
Корутины, долбанные корутины!
Эта хрень прям знатно меня потаскала, пока не заработала как надо. Как и с синглтонами — пока не до конца понял как с этим работать, но понял зачем
Самый лютый вызов
Но самым сложным для меня оказалось научить персонажа спрыгивать с лестницы вбок, здесь я даже прибегнул к помощи всех своих знакомых, кто хоть как то шарит в теме xD
О самой игре
Бегаешь, стреляешь в монстров, собираешь монеты и идешь от точки респауна до выхода. В игре всего 3 уровня. Игра скорее воплощение всех задумок для получения ОС, исправления багов и тем самым — прокачки себя как разработчика
Первым игроком стала моя дорогая жена. При всей её любви к компьютерным играм, она никогда не играла в платформеры и моя игра стала для неё настоящим вызовом, а для меня — отличным способом собрать ОС от замотивированного, но неопытного игрока
Весь игровой мир нарисован тайлом с установленными правилами рисования. Это оказалось безумно удобно. Один раз настроил и не паришься
Что дальше?
Теперь я хочу попробовать создать похожий платформер с собственным ассетом для игрового персонажа, мира и мобов, наполняющих его, но все ассеты и логику за меня напишут нейросети. Позволю себе лишь минимальные корректировки ну и настройки в самом Unity. Потом добавлю в игру интересные РЕВОЛЮЦИОННЫЕ (xD) механики и кучу пасхалок
Но на самом то деле я уже здесь прибегал к помощи ChatGPT и он очень помогал мне тогда, когда в сообществе помочь не могли
Оставлю здесь ссылку на игру, если кто хочет заценить. Буду рад обратной связи и описанием найденных багов!
Обязательно поделюсь с вами, когда из этого что то получится. Спасибо за внимание!
Поделюсь с вами всеми полезностями что для себя надыбал
- Крутой сайт с ассетами платными и бесплатными
- Курс Unity 2D C# по которому я учился
- Тут качал шрифты
- Курс геймдева Unity от CourseHunter, который мне рекомендовали, но сам еще не смотрел его
- Ультра крутая обучалка C# с проверками знаний и заданиями
- Интересная статья про реализацию классного прыжка в платформере на Unity
- Нейросетка DALL-E для рисования. В ней можно намутить себе ассеты, я уже проверил, получается!
- Самый лучший помощник - ChatGPT
Всем пока!
Корутины кажутся стрельбой из пушки по воробьям.
Синглотыне не зло само по себе, если по своему смыслу объект может существовать лишь в единственном экземпляре. И тем более если код упрощается и становится меньше. Возможно, стоит сократить их количество до единого менеджера. Либо задействовать внедрение зависимостей, раз уж не побоялся лезть даже в корутины.
Синглтоны именно зло сами по себе)00)
Да нихрена.
Хрена-хрена)
Лучше маленький, аккуратный, хорошо сделанный синглтон, чем передача того же говна по десять раз из рук в руки (и это ещё если не нарвался на копирование памяти или нулл референсы).
Инверсия контроля же не просто так. Да и если приходится говно из рук в руки пепедавать, то это симптоматика какой-то проблемы. Вот тут и вступает в дело утверждение "зло само по себе", поскольку позволяет эту симптоматику скрыть.
"Зло само по себе" означает, что у него нет полезных применений. Если вся архитектура игрушечная (или отдельно взятый её участок), то синглтон вполне употребим. Главное вовремя оценивать проблемы роста, и если архитектура вырастает из решения, то рефакторить его. А городить огород ради структуры с десятком полей - маразм.
Когда люди обсуждают подобные вопросы, речь идет не о краевых случаях синтетических коней в вакууме. Да, открывать зубами пластиковые упаковки возможно и иногда даже можно. Однако это абсолютно всегда вредно.
В качестве примера проекта, который во всём следует только лучшим практикам, рекомендую ознакомиться с FizzBuzz Enterprise Edition.
Проблема погромистов нынче не в том, что они пишут херовый код и списывают это на неидеальный мир. Проблема в том, что они считают это нормальным.
Так беда в том, что нет однозначных и универсальных критериев качества. Кроме быть может одного: "лучший код - тот, который не написан".
Я вот считаю преждевременное переусложнение одним из плохих признаков. Некоторые вещи сложны и не допускают тривиальных решений, но если там расти нечему, то делать арзитектуру на вырост не нужно (главным образом потому что не угадаешь, что именно от неё потребуется завтра).
Еще раз, никто не отрицает прагматизм. Только вот вещи нужно называть своими именами. Если я создаю техдолг, он остается техдолгом даже если в этот код никто и никогда больше не залезет. Синглтон же для меня остается на шкале "плохой, никакой, хороший".
Я тоже не сторонник накопления техдолга, но где грань между избавлением от техдолга и оверинжинирингом? По мне так они по одну сторону лежат.
Правильный вопрос. И вот мой взгляд: жить в грязи допустимо, но мириться с этим неправильно. Если мы можем делать лучше, нет ничего плохого в том, чтобы стремиться у этому.
А терминами типа преждевременной оптимизации и оверинжиниринга очень любят злоупотреблять те, кто предпочитает вообще не вдумываться в то, что они делают и зачем. Это не обвинение, а просто наблюдение за профсреду.
Так а почему бы и не называть их своими именами? Синглтон - паттерн проектирования, который был описан бандой четырех. А личный опыт взаимодействия с ним - личный опыт взаимодействия. При чем здесь абсолютное зло или техдолг?
Прошу прощения, но я по второму кругу не пойду. Перечитай ветку.
Спасибо за совет! Подъизучу тему и попробую реализовать реальной пользой в следующих проектах. Сейчас я использовал все это скорее ради изучения, но понял что слишком глубоко для текущего навыка копнул 😂
Главное что закончил, всё с опытом придёт. Заодно будет понимание, что где применять не следует (часто это не менее важно, чем знание подходящего инструмента).
Не стоит боятся Coroutines это достаточно удобный базовый функционал предоставленный Unity. Его не обходимо изучить и использовать. Он отлично покрывает потребности небольших проектов.
Я разобрался с корутинами и начал использовать этот подход всегда, когда надо что то включить/выключить, а потом через N секунд вернуть всё как было. Я что то делаю неправильно? Есть другой способ проще это делать?
Тут дело в том, что корутины нужны далеко не только для этого, чем "ни в коем случае не для этого".И да, не знаю особенности реализации корутин в юнити, но высокоточный таймер я бы на этот механизм не закладывал.
Надо на DTF доработку, если нажал стрелку вниз - оставь обязательный коммент, а то нихрена не понятно что им не понравилось?
Это же просто кнопка скачивания)
Комон, в интернете оферта подразумевает, что если потребителю что-то не нравится, он не обязан объяснять, почему.
Над кнопкой скачивания поржал 😂
Сам увлекся Unity и пока тяжко без опыта в программировании, благодарю за материал!
Желаю удачи в изучении! Я сейчас понял что в первые пару недель было до того тяжело, что голова пухла и весь код перед глаза казался дикой дичью, которую я никогда в жизни не постигну. Сейчас это для меня все еще дичь и после пары дней перерыва с трудом ориентируюсь в своем же коде, но все же уже сильно быстрее вникаю и сильно легче писать новый код. Поэтому желаю вам с легкостью преодолеть этот барьер. Дальше будет легче!
Удачи, будущих проектах. Небольшие советы. Лучше использовать не GetComponent а TryGetComponent. Это позволит избежать лишнего выделения памяти. Что бывает критично при частных проверках. Так же с паттерном синглтон стоит быть аккуратным. При всей его внешней простоте и удобстве, он сильно влияет на гибкость и масштабируемость программы. Нужно четко разграничивать область его применения, и понимать в чем он будет удобнее для данной задачи.
Спасибо за подсказки! Буду держать в голове.
А в чем у Get и Try разница работы ?
При использование GetComponent редактор создаёт отдельный объект в который пытается поместить искомый компонент. Это приводит к выделению дополнительной памяти. этот происходит только в редакторе но может критично сказаться на тестирование приложения. Плюс требуется создание отдельной переменной для проверки компонента на null. Что бы решить данную проблему было создано новое api TryGetComponent. Главное отличие в том что метод возвращает bool, а нужный компонент назначается атрибуту с модификатором out. Это позволяет избежать выделения памяти. Плюс код легче читается и выглядит чище.
Ещё одна из ценных оптимизаций для начинающих - это искать и связывать объекты и компоненты один раз при создании или изменении, а не на каждом апдейте.
Здорово, я почти понял, спасибо! А с использованием FindObject таких проблем нет ?
Это довольно дорогостоящия операция. Так что использование ее оправдано только при инициализации классов. И последующем кэширование нужных объектов. Как отметили ниже, никогда не стоит использовать поиск объектов, в методах вызываемых каждый кадр или чаще (Update, FixedUpdate и т.д.) Часто люди опасаются использовать кэширование объектов через инспектор. Считается что это нарушает инкапсуляцию, ссылки могут потеряться. Или кто то сменит их случайно. Но это вполне рабочая схема если использовать ее внутри одного префаба. Нужно следить за балансом времени и сложности кода. Понимание того что лучше для конкретного проекта приходит с опытом.
Можешь вместо синглтонов попробовать zenject, просто в одном классе биндишь все классы которые тебе нужны, и из любого другого класса можешь их доставать, очень удобно, и не будет вероятности получить null ref
Удачи тебе, надеюсь у тебя всё получится. Не сдавайся, если что-то не будет получаться
Удивительные слова от хейтера, спасибо! 🔥☺️
А ты именно БА или ПМ?
я чисто БА, у нас в команде есть продукт овнер как функциональный лидер проекта
Список почему-то напомнил классику
ну да, коряво написал, это правда xD