b_ear, заминусил, но по большей части из-за детского поведения. Хотя сейчас я и призадумался, виноват ли человек, который выделяется несколько... эм... ребяческим поведением только в силу своего возраста (если это действительно так). Припоминаю, что и сам был таким Однако это не отменяет факта, что gamedev - это серьезная, сложная область, и подходить к ней нужно соответственно, если хочется, чтобы тебя воспринимали серьезно. И несерьезные, оффтопные, трешевые посты вызывают раздражение лично у меня (свои в 10 лет я бы воспринимал также). А насчет сабжа... думаю, что было бы здорово делать предупреждение при добавлении ответа, если сообщение имеет нарушения (как по правилам орфографии, так и сайта: чрезмерный капс, мат, слитые слова, url'ы, не помеченные [url]).
Сообщение отредактировал Leonin - Суббота, 20 Июля 2019, 18:24
Здравствуйте! О проекте вы можете почитать здесь: тык. За подробностями можете обращаться в личку. Заранее должен сказать, что окончательного и полного вижена проекта нет (но есть основной :)). Поэтому на первых порах возможна корректировка каких-то аспектов игры. На данном этапе замечаю, что собственных рук катастрофически не хватает, поэтому ищу людей. Теперь конкретно, кого я ищу.
Гейм-дизайнер. Необходимо будет прорабатывать основные идеи проекта до ума, предлагать новые идеи, подробно описывать их функциональное назначение и чем они будут интересны игрокам, работать с диз. доком. Будет плюсом, если вы разбирайтесь в Unity. Будет плюсом, если возьметесь за создание уровней игры (для этого предоставлю необходимый инструментарий).
Человек, разбирающийся в стиле. Нужно будет прорабатывать определенные стили для каждого набора уровней, рисовать узоры. Преимущественно - это абстракционизм и минимализм с неоновыми оттенками. Короче, фильм Tron Для работы предоставлю некоторый инструментарий внутри редактора. Текстуры создаются автоматически, ваша задача лишь задавать основные параметры уровня, цветовую гамму, общую идею для какого либо конкретного стиля. Будет плюсом опыт работы в Unity.
Сценарист. Пока не уверен, что сюжет в игре вообще будет присутствовать, но если найдется человек, который согласится его написать и не будет слишком поздно, то почему нет?
Программист. Одному прогать реально становится тяжело. Слишком много вещей необходимо писать. Опыта в коллективной разработке у меня, к сожалению, нет, но пора бы уже начать Язык C#. Будет огромным плюсом опыт работы c GIT, шейдерами и Unity.
Комьюнити менеджер/маркетолог. Нужен человек, который согласится вести темы на различных тематических форумах, отвечать на вопросы о проекте, вести группы в соц. сетях. По возможности продвигать проект в массы. Огромным плюсом будет знание английского.
Тестер. Пока не особо необходим такой человек, но если есть желание - буду рад. Нужно будет искать баги, составлять их описание.
Звукорежесер. Пока проект не на той стадии, чтобы об этом задумываться, как и в случае с тестером, но если ты существуешь - отзовись.
Насчет оплаты... Тут пока сложно и понимаю, что в этой теме, скорее всего, будет не очень много смысла, т.к. проект по большей части движется на двигателе энтузиазма, но попытка не пытка. Есть некоторый бюджет в 70к, который потихоньку растет посредством вычета из личной ЗП, но оплачивать профессиональных разработчиков я, увы, не имею возможности, так что оплата по большей части символическая, с целю пополнить портфолио. Потому сверхнавыков не требую, как и постоянное участие в проекте. Оценю любую посильную помощь. Будет здорово, если сможете совмещать несколько ролей. Оплата обговаривается индивидуально. О коммуникации и рабочем процессе. Связь в дискорде. Возможно парное программирование и работа через team view'ер. Также буду рад инициативе по развитию проекта и вашему участию в его жизни. Игра делается в Unity (с HDRP), как наверное уже поняли. Репозиторий в BitBucket, VCS - Git. Целевая платформа - PC. От себя гарантирую адекватность и самоотдачу. Жду от вас хотя бы первого. Для связи можете писать в здесь в теме или в вк: тык
Сообщение отредактировал Leonin - Воскресенье, 21 Июля 2019, 04:32
Делал свой простенький вело... state machine, заняло 1 или 2 дня вроде. ИМХО, если вам не нужен супер функциональный state machine с визуальным редактированием, то вполне самому можно написать.
Сообщение отредактировал Leonin - Среда, 17 Июля 2019, 19:41
Согласился бы, с условием, что Вы не обязываете к работе над проектом, как что-то должное. Да и зачем офис, если можно кучкой пойти в антикафе и арендовать комнату? Сидите себе за ноутом, попиваете чаек с печеньками, потихоньку пилите в приятной неформальной обстановке. Можно было бы даже с хозяином заведения договориться на постоянное посещение. Это гораздо дешевле. А деньги потратил бы на саму разработку и маркетинг, поиск хороших специалистов. В конце концов, вы делаете игру, а не играете в директора.
Как-то мне предлагали заняться фриланс-проектом по обучению детей английскому языку. Но большинство TTS работали на облочных технологиях и требовали соединения с интернетом, что нам не подходило и что я пытался вдолбить PM'у. Рассматривали следующие варианты, но особо в них я не вникал, т.к. уже заранее настроился отказаться от участия в проекте: https://www.nexmo.com https://assetstore.unity.com/packages/add-ons/machinelearning/google-cloud-speech-recognition-vr-ar-desktop-desktop-72625 https://assetstore.unity.com/packages/tools/audio/mobile-speech-recognizer-73036 https://assetstore.unity.com/packages/tools/integration/android-speech-tts-45168 https://lightbuzz.com/speech-recognition-unity/#comment-12397 http://www.kokosoft.pl/forums/topic/offline-working-and-letter-recognition/ Еще Siri рассматривали.
Когда будут уроки более высокого уровня? Не в плане качества видео, а в плане создания архитектуры проекта и кода, практические советы для часто возникаемых задач? Про паттерны (DI и IOC, КОП, state machine), про scriptable object, сериализацию, Assembly Defination'ы, пресеты настроек, переходы между сценами, применение мультипоточности в рамках юнити? Если что-то уже было из этого, то прошу прощения, смотрел уроки бегло...
Сообщение отредактировал Leonin - Воскресенье, 14 Июля 2019, 22:19
Должно быть, все уж и забыли про этот проект. Но все же я выложу сюда то, что сделано на данный момент. Постепенно буду вливаться в проект с новыми силами, т.к. ВУЗ наконец-то закончил и времени теперь стало побольше Сама концепция проекта не изменилась, но претерпела некоторое переосмысление: сюжета, скорее всего, не будет, как и открытого мира. Будет просто набор головоломок с общей механикой, но разным стилем. Пока не будет играбельной демки с парой уровней - писать буду редко, но работа идет Видео здесь: Prototype 7
---------------------------------------- Запись №1. 16 Июля 2019, 21:26 ---------------------------------------- О возвращении к проекту Наверное, здесь я буду потихоньку вести свой блог и хоть как-то разогревать интерес к игре и разбавлять коддинг чем-нибудь еще. Буду описывать различные механики над которыми работаю/работал, мысли о дальнейшей судьбе проекта и отчасти своей, да и вообще о геймдеве в целом. Короче, дневник разработки с примесью личного дневника Для затравки напишу о том, почему же меня не было целый год с лишним и почему вернулся. На самом деле все просто: работа + учеба. Эта формула, которая высасывала все мое время. Работа началась где-то в сентябре прошлого года, а в апреле была последняя запись от меня в этой теме. Летом тоже было не до проекта по череде некоторых событий, которые я просто опишу "семейные обстоятельства". + я занимался одним небольшим augmented reality проектом, как фрилансер, что было моим первым опытом, удавшимся наполовину. Месяц назад я отучился. Еле как, почти висел на волоске от исключения, но обошлось. Отучился по специальности АСУ ТП, к слову. Но остается работа. Стандартный график с 7:30 до 16:30 + полтора-два часа на пересадки. Оставшегося времени явно не хватает, чтобы уделять достаточно времени проекту. Но прелесть в том, что бывает попадается сменный график 2 через 2, в котором времени гораздо больше: фактически работаешь 12 ч в 4 дня, в другие 12 часов ночной смены тупо прихожу поспать на скамейке. До конца месяца я работать буду в день, потом переводиться на место, более подходящее моей специальности, и есть большая вероятность, что там буду работать в смену на постоянной основе, что даст возможность гораздо больше уделять времени проекту, а не по 3 часа в день, как сейчас. А вернулся я просто потому что я чувствую, что это то, чем я хотел бы заниматься. Мне нравится программировать, вести свой проект, решать задачи и видеть, как на твоих глазах проект мало по-малому развивается. Дальше буду писать уже конкретно о проекте, а не о моих метаморфозах в жизни, но и их исключать не буду, хоть и оффтоп. p.s. Обновил начальный пост в соответствии с текущим состоянием проекта и его будущем.
---------------------------------------- Запись №2. 17 Июля 2019, 21:25 ---------------------------------------- Об архитектуре кода ОСТОРОЖНО! Длиннопост. Решил написать о том, как я конструирую код, какой философии придерживаюсь и что думаю обо всем этом. О программировании высокого уровня Под высоким уровнем я сейчас имею ввиду не качество кода, а программирование на уровне абстракций, взаимоотношений классов, паттернов, парадигм и т.д. Наверное, у каждого программиста наступает такой момент, когда он от кодинга методов и алгоритмов переходит к программированию, на котором уже думает о правильной организации классов и отношений между ними. Это та сторона в программировании, в которой нет пределу совершенству: одну и ту же задачу в рамках фичи можно решить множеством различных способов, и нельзя сказать, какое из решений будет правильным (по-крайней, мере заранее). Да, есть паттерны проектирования и парадигмы программирования, но и это не панацея, а лишь инструменты. В программировании алгоритмов и методов тоже есть вариативность решения задачи, но там правильное решение как-то более очевидно. Был момент в процессе моего обучения, когда я старался писать код идеально, страдая перфекционизмом. И это было с одной стороны хорошим опытом, с другой... А с другой это просто невозможно. Это занимает такое количество времени, что возникает чувство, что ты топчешься на месте, застрял в цикле while(true){ CodeReview(); }, переписывая и занимаясь рефакторингом написанного кода. В конце концов, это демотивирует, т.к. результата по сути и не видно. Да, код чистый и красивый, но что толку, если это видишь только ты? Да и как показывает практика, даже красивый и простой код, бывает, приходится переписывать и редактировать. ИМХО, нужно заниматься рефакторингом, оптимизацией и прочее только тогда, когда это действительно нужно. В 75% случаев я не возвращался к написанному коду - работает и ладно. Зачем его трогать, если все и так более менее стабильно? О паттернах проектирования К этим вещам у меня сложилось скептическое отношение. Возможно, я еще не постиг дзен и не могу правильно применять данные вещи, но первый опыт с подобными вещами был отрицательный. Однако есть некоторые паттерны, которые я применяю на практике, часто в видоизмененном формате, и они действительно облегчают жизнь. Особенно полезными оказались state machine, singletone (надеюсь, тут меня не закидают помидорами тру-программисты) и фасад. Другие паттерны чаще всего лишь осложняли код, но, скорее всего, я не умею правильно их готовить или в контексте Unity в них мало смысла. О парадигмах и принципах программирования В плане принципа программирования я ближе всего к KISS. Еще есть YAGNI, GRASP, DRY, о которых я знаю, но, ИМХО, они лишь вытекающие из KISS. Это довольно абстрактные "субстанции", о которых сложно писать: для кого-то один кусок кода может показаться простым, для другого тот же кусок - чрезмерно сложным. Думаю, что не стоит заморачиваться над этим слишком сильно. Т.к. я пишу код один, то пишу как можно удобнее для себя, однако в голове вертится неприятная мысль, что, если придется работать с кем-то еще, то придется долго и упорно объяснять, как же все это работает. В плане же парадигмы, то КОП нравится мне больше всего. Нередко слышу, что чаще всего агрегация лучше наследования. И КОП, по сути, и есть призыв к агрегированию, конструированию сущностей через независимые модули. Да и Unity по большей части придерживается данной концепции через компоненты. Хотя и тут есть подводные камни. Есть еще такие вещи, как IoC, DI, DIP, SL. Как-то пытался я настроить проект под Zenject, но ничего путного у меня, к сожалению, не получалось. Много времени уходило на изучение АПИ, были и баги. Да в общем-то Unity и сама уже частично реализовала внедрение зависимостей через систему сериализации в переменные класса. Можно создать какой-нибудь ScriptableObject, хранящий данные, сохранить как ассет и внедрять его через инспектор. Чем не DI? Ну а методы FindObjectWithType, GetComponent... Это же самый настоящий Service Locator! К которому, к слову, у меня не очень хорошее отношение. Выводы За время жизни проекта кодовая база сильно изменялась. Прогрессирует не только проект, но и я: глядя на код годичной давности мне хочется перекреститься и забыть, что это писал я. Уверен, что через год будет так же Сейчас я не буду описывать, как все устроено в проекте. Больше смысла будет, если я дам советы, которые я применял в своем проекте. Естественно, они не являются истинами в последней инстанции и у вас должна быть своя голова на плечах. Но лично для меня эти выводы вполне обоснованны. Буду рад критике от более опытных программистов и гейм-девелоперов. Список неполный, но написал первое, что вспомнилось.
State machine может действительно облегчить вашу работу с кодом. Вообще, старайтесь делегировать функционал по возможности и абстрагироваться, но без фанатизма. Этот совет применим не только в рамках архитектуры кода, но и в рамках GameObject'oв (например, корневой объект, содержащий 2 дочерних: один для физики с меш-коллайдером, другой с меш-рендерером для визуального представления; сам же корневой объект играет роль "менеджера" этих дочерних). Чем-то это напоминает MVC модель.
Отделяйте функционал от данных. Держите данные в другом классе, в ScriptableObject, еще где-нибудь, но не в самом классе. Просто хотя бы потому, что это повышает читаемость.
Отделяйте поведение в редакторе и в игре. Не пишите поведение для редактора и для игры в рамках одного класса.
Учитесь писать тесты. Я открыл их для себя недавно и применял относительно мало в проекте, но они действительно спасали мою задницу от коварных ошибок и багов. К сожалению, они отнимают время. Если класс (точнее его функционал) нестабилен, то его тесты переписывать тоже, скорее всего, придется вместе с изменениями. Каюсь, мне очень лень их писать
Не пишите код идеально, пишите его как можете. Сейчас в моем проекте много кода, который не мешало бы переписать с учетом новых знаний. Но делаю я это редко, т.к. если он работает стабильно и без тормозов, зачем менять что-то? Просто пишите дальше, переписать всегда успеете. На своем пути у меня уже появилась отдельная папка с проектами qBox (old1), qBox (old2)...qBox(oldN). По началу да, переписывать действительно было проще, чем рефакторить, но это на ранней стадии развития проекта. Позже уже сами будете 100 раз думать, прежде чем переписать все заново.
Для себя я поставил следующие приоритеты в программировании (в порядке убывания важности): стабильность, простота, удобочитаемость, гибкость, производительность. Естественно, что если один из пунктов на слишком низком уровне, я обращаю внимание на это и жертвую более важным параметром качества кода по дефолту.
Старайтесь отделять логику от привязки к движку. Делайте обычные классы, не являющиеся MonoBehaviour'ами. Их легче тестировать и использовать где-нибудь еще. Единственный минус - их в инспекторе не видно, но и тут можно создать класс-медиатор при желании.
Старайтесь избегать вызовов Update в разных компонентах одного объекта. Особенно при работе с transform. Иначе возникает проблема порядка вызовов Update. Вообще, лучше иметь UpdateManager, который при старте сцены собирает все объекты с интерфейсом ITickable и вызывает метод Tick(), аналогичный апдейту. Зачем? Это производительнее. + можно менять сигнатуру метода Tick() и контролировать порядок вызова без Script Execution Order'a.
Старайтесь не вызывать GetComponent вне собственного класса. Я сознательно ограничил себя этим решением. Не уверен насчет его правильности, но лично у меня возникает диссонанс, когда я знаю, что любой класс при желании может получить данные о другом классе через этот метод. Да, удобно, но, по сути, это Service Locator, который нередко позиционируется, как антипаттерн. Класс не должен знать о других классах больше положенного. Transform я вообще оборачиваю в интерфейс, предоставляющий доступ к его полям, и реализую его интерфейс абстрактным классом, который контроллирует валидность при попытке изменить его поля.
Не пишите комментарии и не документируйте код, который часто меняется. Часто придется при изменении класса менять и комментарии или XML документацию. Старайтесь писать так, чтобы было понятно, что происходит и без комментариев.
Старайтесь конструировать архитектуру так, чтобы легко можно было выделить слои, от более общего к более конкретному. Я имею ввиду, что желательно конструировать систему так, чтобы компоненты системы (конкретные сущности, стейты и прочее) не могли знать о самой системе на ее более высоком уровне (контроллеры, менеджеры), но система имела право общаться со своими компонентами. В общем, это идея инкапсуляции и паттерна фасад. Общение снизу вверх желательно делать через интерфейсы и делегаты. В общем, инкапсулируйте систему и абстрагируйтесь от ее внутреннего устройства.
Сообщение отредактировал Leonin - Пятница, 19 Июля 2019, 17:51
pixeye, А, я сразу не взглянул на ваш ник Натыкался на видюшки у вас в ютубе, когда искал о решениях архитектуры в юниты как раз, сразу понял, что это вы, когда увидел слово Actor К слову, очень даже неплохой подход к разработке, p.s. Передаю привет Флаффи и желаю удачи в разработке
1) Не рекомендую использовать монобехейверы для дата компонентов. Используй обычные C# классы.
Разве не лучше использовать ScriptableObject для хранении даты? Можно создавать их в ассетах и, кажется, они сохраняют значения после плэинга в эдиторе. Хотя, ScriptableObject лучше подходит для данных, в которых настраивается конфигурация объекта, а не все данные К слову об архитектуре. Не пытались использовать Dependency Injection в unity? Юзаю Zenject, вроде пока вполне себе интересная штука, позволяет сконцентрироваться на том, чтобы класс выполнял только свою задачу, да и зависимости отслеживаются легко: практически метрика связности, сколько классов нужно объекту для нормальной работы. Из минусов правда начальная сложность в изучении и много всяких классов-installer'ов, но зато основной класс не заботится о том, откуда взять нужные связи: их предоставят извне и настраивать систему проще. + наследование от монобеха уже необязательно для внутренних состояний компонента. Причем остается возможность использовать апдейты, корутины, эвэйки, даже если это не монобехи.
Сообщение отредактировал Leonin - Пятница, 01 Июня 2018, 13:02
Банально, для злости брать высокие ноты разных тональностей и красный оттенок с переливами в черное основание и динамичный радиус свечения отлично покажут злость. Мягкие и плавные зеленые пульсации с белыми переливами укажут на спокойствие. Переход в розово-фиолетовый с увеличеной, синусоидной динамикой радиуса покажут на смятение.
Кстати, я искал уже какие цвета какие эмоции обычно вызывают в человеке. Сделал что-то вроде этого пока что:
на данный момент я вижу несколько интересных геймплейных решений в игре, где нужно играть именно геометрической фигурой
Если есть возможность, я готов выслушать ваши предложения Сейчас дорабатываю хождения по разным поверхностям и возможность переключения ориентации (если она имеет смысл и в новой ориентации можно переместиться). Даже для меня выглядит интересно, хоть и немного запутанно, хотя в этом есть свой фан. Планирую сначала дать игроку лишь базовое хождение (эм... модуль перемещения v1.0?) и простой сокобан. После парочки уровней открыть игроку уже возможность хождения по всем поверхностям (модуль перемещения v.2.0 :D) и дать возможность переключаться между этими режимами перемещения. Т.е. в одном случае куб прилипает к поверхности/забирается на нее, в другом - падает с обрыва или толкает ящик. Нужно будет еще как-то обозначить, где находится настоящий "низ", чтобы игрок знал, куда он будет падать при переключении режима. Скорее всего, сделаю отдельной клавишей, при зажиме которой будет указана траектория падения.
ЦитатаChristopher ()
У вас для этого можно использовать свечение по середине, яркость, плотность и цвет этого свечения + нотные мотивы, которые будут тонально передавать ощущения куба.
С яркостью, плотностью и цветом свечения, зависящими от настроения ГГ понятно, но вот с нотными мотивами не очень понял. Если бы ГГ был озвучен, это выглядело бы довольно интересно, если бы ядро как бы дрожало при разговоре, но пока планирую делать реплики в виде окошек рядом с ГГ, где будет текст. Читать, конечно, не так интересно, как слушать, но пока нет возможности делать гол. озвучку. Скоро закончу с камерой и сменой ориентации (ненавижу работать с углами:)) и примусь за перемещаемые ящики.
Сообщение отредактировал Leonin - Воскресенье, 22 Апреля 2018, 00:03
НезНал, Та же edge ориентирована больше на динамику и стиль 8-bit. У меня же ориентирование идет на несколько другой стиль, на более спокойный геймплей и сюжет. Насчет геймлея мне еще стоит хорошенько подумать, как можно отличиться. Есть достаточно идей, вопрос в сложности реализации и в увлекательности. Мне предстоит испробовать прототипы этих идей и определиться, что будет более интересно Ну а куб... он и в Африке куб. Я не ставлю целью взорвать рынок или превзойти всех своих конкурентов, не дорос еще То, что в игре ГГ - это куб и на этом завязан геймплей, не определяет игру как хорошая или плохая. Достаточно сказать, что есть вполне достаточно успешных игр с той же механикой cube-rolling (Induction, QVoid и Cubor, Mirage: illusions), которые внесли свое дополнение в жанр. Даже, откровенно говоря, "слизанные" игры в красивой обертке (Rune Guardian и Cube Crux Lite, практически полностью повторяющие геймплей Bloxorz) имеют некоторый успех. Если говорить о том, чем мой куб отличается от других, так это то, что он живой (насколько это применимо к ИИ) - выражает эмоции, высказывается.
Сообщение отредактировал Leonin - Суббота, 21 Апреля 2018, 15:14
НезНал, Я плохо вижу корреляцию между геометрическим кубом, о котором преподают в школе, и вовлеченнстью игрока, которому этот куб преподавали, в игре. К примеру, edge (и не только) играют немало игроков и кубовой стиль не мешает ей быть популярной игрой Или я неправильно вас понял? Что касается одинокости куба... Это не единственный интерактивный игровой элемент, который я запланировал. Однако то, что в игре многие элемента будут кубообразные - это правда. Тут палка о двух концах. С одной стороны хочется сохранить единообразие стиля игры, с другой - увеличить его разнообразие.
НезНал, Да, кубик - это ГГ, искусственный интеллект. Точнее кубик - это лишь предсталение ГГ в игре, так он представляется игрокам. Хм. А чем робот или андроид отличается от AI в виде куба в плане сюжета, характера? Ну кроме визуального отображения. Ну да, способов передачи эмоций меньше, но и тут можно извернуться. К примеру, сделать цвет ядра внутри куба зависящим от настроения, когда он что-то говорит или происходит с ним
Добавлено (21 Апреля 2018, 13:13) --------------------------------------------- InsaneSystems, Спасибо Да, но там загвоздка в блуме. Старый Post-Processing Stack v1.0 выдает мерцающий bloom со "вспышками", что очень неприятно выглядит: Старый bloom А новый, v2.0 работает только в 2018 кажись, поэтому и перешел, он более устойчивый: Новый bloom Думал даже свой блум попробовать написать, но опять же время.
Сообщение отредактировал Leonin - Суббота, 21 Апреля 2018, 14:41
НезНал, Озвучку я точно сам делать не буду, не мое. В плане визуализации специально брал какой-нибудь простой абстракционный и минималистичный стиль, где особых художественных навыков не нужно, но нужно скорее чувство вкуса и стиля. Программа игры потихоньку пишется. Не скажу, что быстро, но пока уверенно
Поидее мир qBox - это специальное тестовое окружение для Q, в котором тестировался он и в который он заточен. Я накидал какой-никакой сюжет, если хотите - скину в личку, почитайте, покритикуйте.
Для работы предоставлю некоторый инструментарий внутри редактора. Текстуры создаются автоматически, ваша задача лишь задавать основные параметры уровня, цветовую гамму, общую идею для какого либо конкретного стиля. Будет плюсом опыт работы в Unity.