Нужно будет еще как-то обозначить, где находится настоящий "низ"
Покажите определенным цветом, который будет ярче остальных.
ЦитатаLeonin ()
Скорее всего, сделаю отдельной клавишей, при зажиме которой будет указана траектория падения.
Лучше всего сделайте клавишу "прилипания к поверхности", пока она нажата. Это намного лучше будет чувствоваться в геймплее и позволит вручную задавать темп игроку.
ЦитатаLeonin ()
с нотными мотивами не очень понял
V
ЦитатаChristopher ()
Банально, для злости брать высокие ноты разных тональностей и красный оттенок с переливами в черное основание и динамичный радиус свечения отлично покажут злость. Мягкие и плавные зеленые пульсации с белыми переливами укажут на спокойствие. Переход в розово-фиолетовый с увеличеной, синусоидной динамикой радиуса покажут на смятение. Если это обыграть как способ взаимодействия с ИИ, о получится отличное повествование "без слов"
Данный тип общения с игроком будет геймплейно подкреплен(например, при виде опасности будет определенный тип свечения) и решит проблему с диалогами на интуитивном уровне. Только если у вас диалоги не будут напоминать оные из Evangelion :D
Банально, для злости брать высокие ноты разных тональностей и красный оттенок с переливами в черное основание и динамичный радиус свечения отлично покажут злость. Мягкие и плавные зеленые пульсации с белыми переливами укажут на спокойствие. Переход в розово-фиолетовый с увеличеной, синусоидной динамикой радиуса покажут на смятение.
Кстати, я искал уже какие цвета какие эмоции обычно вызывают в человеке. Сделал что-то вроде этого пока что:
Чем больше вы найдете возможностей показать что-то игроку без написания текста, тем лучше. То же самое с управлением в туториале. Просто по разным сторонам расположите клавиши от куба, чтобы было интуитивно понятно, нажатие в какую сторону куда ведет. Тогда играть в это будет более, чем интересно.
НезНал, Вы сможете это полноценно оценить как потребитель только тогда, когда пощупаете это самостоятельно и полноценно. В играх, в которые вы когда-либо играли, я почти уверен, что в большинстве были подобные приемы. Иначе, почему враги красные, а в красные бочки стреляют, чтобы они взорвались? Это все - огромное множество мелких моментов, которые в совокупности приведут к тому, что игра позволит вам не заморачиваться и не спрашивать "а на что нажать, чтобы Х?", потому что разработчик спросил об этом сам себя и уже сделал так, чтобы было понятно.
Если вы когда-либо играли в Half-life, то предоставьте мне хоть одно место, где вам было бы логически сложно осознать, почему оно сделано именно так. То же самое с повествованием. Кроме открывающей и закрывающей заставки, вы больше нигде не увидите кат-сцены только потому, что там повествование происходит внутри геймплея.
То же самое с левелдизайном: иногда вы просто посмотрев понимаете, куда нужно идти. Например, DmC отлично показывает геометрией уровня о том, куда стоит идти, акцентируя внимание специальными линиями на уровне, которые образую стрелку сами из себя.
Тут предлагается точно такой же подход. Вы будете знать, что враг впереди только посмотрев на свечение кубика и вам сразу станет ясно, что сейчас что-то произойдет. На самом деле, это чуть ли не целая наука.
вообще-то красный цвет - мой любимый. во всех питейно-развлекательных заведениях мы видим преобладание красных цветов. молодежь любит разнообразие цветов (смотрите детские комнаты), поэтому я и предлагал использовать все цвета радуги по всем уровням (например: очень темнофиолетовый, темнозеленый, красный, светло-голубой, золотой).
далее вы пишите высокопрофессиональные предложения, но я как-то давно уже перестал верить в авторитеты, уж больно часто видел опровержения постулатам.
например: в одной из соседних тем парень пишет, что первые хитовые игры, на которых сколотили свои миллионы корпорации, были созданы начинающими одиночками, а не командами профессионалов. кратко о себе в прогах дуб липовый
Сообщение отредактировал НезНал - Воскресенье, 22 Апреля 2018, 00:39
НезНал, Красный цвет в психологии. Конкретно нам нужны первые строчки, обозначающие то, о чем я говорил:
Цитата
он символизирует Янь – энергию
То есть, активные действия, предназначенные на какие-то определенные действия.
Красный и желтый цвет привлекают внимание и способствуют повышению аппетита, увеличивая продажи ресторанов и баров в конкретно вашем примере.
Так же, банальное изменение цвета само по себе будет означать какие-то изменения внутри игры. Видели, как строятся уровни в The 3rd Bithday? Каждый уровень постепенно становится более агрессивным на ощущения, потому что нагнетается атмосфера того, что происходит в игре.
Добавлено (22 Апреля 2018, 00:34) ---------------------------------------------
ЦитатаНезНал ()
молодежь любит разнообразие цветов
Молодежь в детских комнатах не доросла до того, чтобы играть в игры полноценно) Там используется просто смена внимания на акценитрующие элементы)
вот во все это я и не верю. но не вижу смысла продолжать спор, ибо тема создана не для этого (а я не спец по опылению чужих мозгов, хотя мог бы привести и примеры опровержения вашим утверждениям прямо из игр). кратко о себе в прогах дуб липовый
Сообщение отредактировал НезНал - Воскресенье, 22 Апреля 2018, 00:46
зачем, я вас в любом случае не переубежу, вы у меня не первый спорщик на подобные темы, и вы меня не переубедите, и я это прекрасно понимаю, а вы? кратко о себе в прогах дуб липовый
Сообщение отредактировал НезНал - Воскресенье, 22 Апреля 2018, 01:02
Суть не в переубеждении, а п наглядных примерах из игр, которые смогут показать что-то конкретное. Если лично я такие увижу, это прибавит мне опыта. Так что, если есть желание... ЛС открыто Но это уже оффтоп очередной.
Блин 3 раза начинал делать подобную головоломку... Теперь понял как надо было А коментарии "НезНал" не принимай близко - его Имхо прет через край во всех постах на форуме... Более мощный компьютер глючит быстрее и точнее.
Сообщение отредактировал BrightSpot - Воскресенье, 22 Апреля 2018, 04:05
Использую его в 2017.0.1f3, всё ок, бывают некоторые проблемы, но они так же связаны с бета-версией этого PP 2.0 К слову, на мерцание как-то не обращал внимания, разницы между 1 и 2 версиями в этом плане у себя в проектах не замечал, забавно. Но в вашей игре действительно, второй вариант смотрится гораздо приятнее.
Блин 3 раза начинал делать подобную головоломку... Теперь понял как надо было А коментарии "НезНал" не принимай близко - его Имхо прет через край во всех постах на форуме...
три раза. видимо не дается тебе программирование, что-то ты в нем не понимаешь. но вот как относиться к другим ты верно учишь. наверное.
мои посты близко не принимать я и сам не раз писал (тс может подтвердить). но и полный бред других принимать за чистую монету я тоже не советовал. кратко о себе в прогах дуб липовый
Сообщение отредактировал НезНал - Воскресенье, 22 Апреля 2018, 11:51
Должно быть, все уж и забыли про этот проект. Но все же я выложу сюда то, что сделано на данный момент. Постепенно буду вливаться в проект с новыми силами, т.к. ВУЗ наконец-то закончил и времени теперь стало побольше Сама концепция проекта не изменилась, но претерпела некоторое переосмысление: сюжета, скорее всего, не будет, как и открытого мира. Будет просто набор головоломок с общей механикой, но разным стилем. Пока не будет играбельной демки с парой уровней - писать буду редко, но работа идет Видео здесь: 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
