Только в этом случае проект никогда не будет готов. Это же деятельность ради деятельности, а не ради результата. В этом нет ничего плохого, но для коммерческого продукта такой подход не подойдёт.
Другое дело, если уже после запуска игры дать игрокам инструменты и позволить делиться своими творениями. Ну то есть модостроение и прочие штуки никто не отменял. Может, разработчиками NMS стоило в эту сторону больше развивать игру — люди могли бы создавать свои планеты, звёздные системы и галактики )
Мне кажется, так всё же не стоит писать. Лучше всё так же в InputManager настроить необходимые кнопки и использовать их алиасы в коде. Тогда даже не придётся через «или» перечислять все варианты.
А вам крестовина не натирает большой палец до огромных мозолей? =) Я всегда страдал от этого, играя в GG. Стим контроллер случайно как раз в этом плане не удобнее?
У меня возник вопрос по поводу виктимного поведения. Откуда оно, такое поведение, берётся?
И ещё один, по поводу объективации. То есть вы считаете, что объективации всё же нет? Или что не в ней причина изнасилований? Или что причина, но не единственная или недостаточно весомая?
Очень уж короткая статья у вас получилась. Читать было интересно, но как только я приготовился принять в себя гору информации, эта информация уже кончилась. Я даже не против 10-й раз прочитать одни и те же советы (т.к. у вас они всё же не уникальны), но чтобы их было побольше. Так хоть можно было бы удостовериться в правильности одних и неверности других.
Да уж, немаленькую работу вы проделали. Мне только предстоит окунуться во все эти радости и, учитывая, что опыта в подобных делах у меня практически нет, надеюсь, мне так же удастся всё это победить )
Может, я скажу полнейшую глупость, но нельзя ли в таком случае иметь две тепловые карты — передвижения и видимости? Карта передвижения строится с учётом только вертикальных и горизонтальных передвижений, а видимости — уже с учётом диагональных ходов. Тогда по карте видимости можно будет определить, видит ли монстр игрока, а передвигаться будет уже по другой карте.
По-моему, это даже не слишком похоже на костыль, потому что и в реальной жизни мы можем видеть что-то, но не иметь возможности добраться до этого объекта по прямой.
В этом случае можно будет использовать «прозрачные» препятствия (окна, ловушки, заборы), сквозь которые монстр может увидеть игрока, но будет вынужден преследовать его по другому пути.
Спасибо за информацию. Значит, меня ожидают те же проблемы. Хотя, может быть мне хватит деревьев такого размера, т.к. никакого сложного AI я делать не собираюсь, и деревья тут только для того, чтобы были )
Напишу, когда доделаю, чтобы работали, собственно, сами деревья =)) А то я начал, и так увлёкся Editor'ом, что всё это работает пока что только в теории.
Но вкратце, ноды рисуются при помощи GUI.Window, а кривые — Handles.DrawBezier. Всё вот так вот просто =)
если вы поставите [Header()] перед приватным полем, то ругаться Unity не станет, но никакого заголовка не отобразит
Если сделать [SerializeField], то отобразит =) Вместе с полем, кстати. Тоже очень удобный аттрибут, когда нужно предоставить возможность редактировать поле из редактора, а в коде, скажем, сделать публичное свойство с необходимыми геттерами-сеттерами.
Почему же нельзя редактировать поля без открывания кода? Наследуемся от SO, заводим нужные поля, создаём ассет с этим SO, жмём по ассету, инспектор показывает поля. И не нужно создавать лишние GameObject'ы, которые, например, меня очень сильно раздражают и травмируют мою неокрепшую психику.
Вот, например...
… мои потуги в реализации BehaviorTree — инспектор вполне себе показывает поля SO, который на самом деле вообще внутри другого ассета лежит.
А не думали для этих нужд заюзать ScriptableObject вместо MonoBehavior? Я не гуру Юнити и только недавно начал постигать полезность SO, но по-моему, если нужно сделать что-то, для чего не нужно визуальное отображение (т.е. как раз таки настройки чего-либо), SO подойдут в самый раз.
Не нужно сопротивляться появлению нормальных образовательных программ по разработке игр. На западе они уже давно есть, и поэтому там геймдев как-то посерьёзнее развит. Другое дело, что конкретно эта программа как-то не внушает особого доверия.
Интересный заголовок, хорошая КДПВ, но внутри ни одного вопроса не раскрыто. Ни про генератор, ни про хрущёвки, ни про AssetStore. Только какие-то уж совсем базовые вещи, которые и так по 100 раз уже рассказаны =( Обидно.
Другое дело, если уже после запуска игры дать игрокам инструменты и позволить делиться своими творениями. Ну то есть модостроение и прочие штуки никто не отменял. Может, разработчиками NMS стоило в эту сторону больше развивать игру — люди могли бы создавать свои планеты, звёздные системы и галактики )
Мне кажется, так всё же не стоит писать. Лучше всё так же в InputManager настроить необходимые кнопки и использовать их алиасы в коде. Тогда даже не придётся через «или» перечислять все варианты.
И ещё один, по поводу объективации. То есть вы считаете, что объективации всё же нет? Или что не в ней причина изнасилований? Или что причина, но не единственная или недостаточно весомая?
По-моему, это даже не слишком похоже на костыль, потому что и в реальной жизни мы можем видеть что-то, но не иметь возможности добраться до этого объекта по прямой.
В этом случае можно будет использовать «прозрачные» препятствия (окна, ловушки, заборы), сквозь которые монстр может увидеть игрока, но будет вынужден преследовать его по другому пути.
Но вкратце, ноды рисуются при помощи GUI.Window, а кривые — Handles.DrawBezier. Всё вот так вот просто =)
Если сделать [SerializeField], то отобразит =) Вместе с полем, кстати. Тоже очень удобный аттрибут, когда нужно предоставить возможность редактировать поле из редактора, а в коде, скажем, сделать публичное свойство с необходимыми геттерами-сеттерами.
Разработчики кормят котов за то, что те делают игры и продают их за хорошие деньги? =)