rukzachini

Я пиарюсь

В юнити с графикой хорошо, а в скором времени с приходом scriptable render pipeline будет совсем хорошо. В Unreal сейчас из коробки графика чуть получше, но это компенсируется обилием плагинов для юнити, да и в любом случае вы в обоих движках скорее упрётесь в свои художественные навыки, чем в ограничения каких-то графических фичей. Я бы при выборе советовал смотреть не на графоний, а на близость языка программирования, доступность документации, удобство лицензии и т. п.

Каждый описанный вами пункт это отдельная подсистема, которую можно написать и оттестировать на совершенно отдельной от остального кода сцене. Общее у них скорее всего только наличие предметов с идентификаторами, которые могут иметь разное представление в интерфейсе и в игровом мире. Туториалы на то и туториалы, что они показывают как можно что-то сделать, они не навязывают конкретной реализации. Просто сядьте и на бумажке распишите подробнее ваши четыре пункта, как оно должно работать, выделите понятные сущности: предмет, рюкзак, быстрый слот и т. п. Напишите сначала в лоб, чтобы работало, потом перепишите, чтобы было красиво. Из полезных юнитёвых классов советую присмотреться к ScriptableObject, в них удобно хранить ссылки на характеристики и разные представления предметов. А в остальном не советую мыслить об инвентаре как о единой монолитной системе, пишите его кусками, причём такими, чтобы при желании с ними можно было работать без графического интерфейса.

1. Проверьте, стоит ли у объекта вашего игрока тег "Player".
2. Привязали ли вы в инспекторе (или где-то ещё) объект рычага к GO.
3. Проверьте, является ли коллайдер у рычага триггером, и может ли игрок с ним взаимодействовать.
4. GameObject.activeSelf может иногда возвращать не то значение, если активность объекта установлена не вами, а кем-то в иерархии. Проверьте, нет ли у вас такого, что в SetActive всё время передается false, например.
Для того, чтобы просмотреть значения в ходе исполнения программы, можете воспользоваться выводом отладочной информации Debug.Log

Приветствую! Нужно съесть манную кашу. Пробовал сначала сам есть - вышла какая то дичь - хотя формально я ее съел, но измазался в ней весь.
Пересмотрел кучу туториалов как есть манную кашу - у всех принцип одинаков, но каждый есть по разному - кто то ложку боком заносит, кто то вообще левой рукой ест. А мне нужно есть через трубочку - я не нашел такого функционала.
Надеюсь у кого то есть годные статьи\видео\примеры, либо кто то может объяснить как есть кашу через трубочку, в идеале на польском.

Нормальный вариант ответа: никто вам не напишет ничего, потому что у вас своя архитектура, свои допустимые либы и все свое, и лезть в чужую архитектуру - это дорого.

Это low poly, просто в определённой стилистике, термин "low poly" сам по себе означает только маленькое количество полигонов. Например, на картинках ниже изображены низкополигональные деревья, но выглядят они по-разному, потому что созданы в разном стиле.
Точно также и "pixel art" означает только то, что при рисовании уделяется большее внимание индивидуальным пикселям, а стилей рисования много, взять хотя бы Sword & Sworcery и Fez. Если вам понравились модельки в определённой стилистике, то вам нужно просто обратиться к автору и заказать их у него, либо найти художника, который сделает вам такие же. Нет никакого единого стиля низкополигональных космических кораблей, который можно нагуглить, в лучшем случае можно зацепиться за название какой-то популярной игры, например "модельки как в майнкрафте".

в майнкрафте всего лишь текстуры стилизованы под "8 бит"
Раз есть знания C#, то Unity

C, C++, OpenGL, OpenAL, Bullet/Box2D, glfw, glm, glew, GLSL, vectors, matrices и вся линейная алгебра. Форматы данных, структуры данных. Пайплайн рендеринга и механизмы работы видеокарты. Ну и UI фреймворк какой-нибудь.

Немного физики, школьный курс математики + линейная алгебра(для начала хватит цикла статей на хабре "линейная алгебра для разработчиков игр"), знание языка C# или C++ на достаточном уровне ну и много других мелочей.

1 Не всегда нужна вся та мощь движка
2 Иногда, очень редко, может не хватать гибкости движка
3 Разработчики могут хорошо знать свой инструмент, но плохо UE/Unity
4 Нежелание покупать движок или отдавать часть дохода создателям движка
5 Эффективность, свой движок или другой узкоспециализированный может быть более эффективным
И ещё тысячи других причин.

Юра Березовский , читать сгодится все то, что полезно для укрепления знаний. Книги по архитектуре, машиностроению, анатомии животных и людей, бодибилдингу (т.к. там хорошо рассказывают про моторику и мышцы).

Конкретнее... Вот, что глазом у жены с полок ухватил:
* Джеймс Гани - Цвет и свет.
* Готтфрид Баммес - Образ человека
* Ф. Делавье - Анатомия силовых упражнений.

И, как всегда, изучать первым делом надо всё. Но укрепляться желательно только в тех направлениях, которые тебя увлекают. Тогда твои навыки попрут в гору.

Основные инструменты артиста имеют или вот такое название:


Wacom - дороже и считаются более крутыми. Huion - молодые, дерзкие, все время норовят куснуть у вакома долю.
Бытует мнение, что даже если сейчас у тебя не получается работать с планшетом, все равно работе с ним стоит уделять минимум 2 часа в день. Привыкнешь.

ArtStation хорошо мотивирует самообучаться.
Роман Гура, вроде, иногда берет учебные группы за денежку. Навык Ромка поднимать умеет как у тех, у кого все кисло, так и у тех, кто уже чего-то добился.
Лео Хао, вроде бы, тоже недавно занимался обучением начинающих.


Кстати, советую запиннить группу "Берешь и рисуешь", она полезная.

Как-то так, в общем. Дерзай.

В юнити нет JS. Скопирую и дополню свой ответ с другого ресурса.

Мне как джаваскриптизеру с десятилетним стажем проще было писать на C#, чем на этом якобы JS. И вот почему:

• Никаких встроенных в JS объектов, функций и API там нет. У массивов, строк и объектов другие свойства и методы. Прокидываются вещи из рантайма юнити, надо искать, что и где. Невозможно взять библиотеку с npm и использовать её в Unity3D. Кроме самых примитивных примеров, типа var a = 2 + 2, код из учебников по JS не будет работать в Unity3D.
  
• Некоторые, казалось бы, очень простые и очевидные, синтаксические конструкции тупо не работают.
  
• Классы не похожи ни на ES6, ни на TypeScript, ни на CoffeeScript
  
• Явное указание типов вроде не обязательно, но иногда компилятор в самый неожиданный момент не может вывести тип автоматически и надо идти и прописывать. Опять таки декларация типов не совсем такая, как в TypeScript или ActionScript, а как описать сложные типы не всегда очевидно.
  
• Нет нормального редактора (MonoDevelop таким не является), который бы поддерживал этот синтаксис, подсвечивал ошибки, давал навигацию и так далее (я уж молчу про linting и рефакторинг).
  

В общем, нельзя просто взять и начать писать на UnityScript. Может быть, если JS (или ActionScript) у вас первый и единственный язык, это проще, чем, скажем, учить C# с нуля, но и то не факт, ибо по шарпу дофигалиард учебных материалов.

В Unity не JS , а UnityScript ,похожий на JS по синтаксису. И на нем можно писать, но так никто не делает, куда больше возможностей и примеров у C#

Для больших игр неминуемо пишется свой инструментарий, потому что художникам надо быстро проверять, как смотрится арт в игре, геймдизайнерам править баланс, нарративщикам добавлять запятые в диалоги и так далее, а заставлять каждого компилять игру из C++-сорцов запрещено международной конвенцией по гуманному обращению с пленными и декларацией прав человека. Поэтому неизбежно будут какие-то тулзы, куда можно скормить png, mp3 или txt, подвигать ползунки и посмотреть, как это будет в игре.
Иногда из этого выходит вот Unity3D или UE, иногда TES Construction Set, иногда оно так и остается в недрах.

Disclaimer: я никогда не работал в геймдеве:)

Советы конечно замечательные, но тут вопрос на тему "состряпать курсач с наскоку" насколько я понял ;) Кроме того, важен "порог вхождения" (то что тяжелее учить - в будущем даст больше возможностей и, в последствии, ускорит время работы значительно). Поэтому совет следующий (от инжа который работает каждодневно во всех перечисленных и не перечисленных выше прогах):
1. самый качественный результат "с наскоку" даст ArchiCAD (тапками не кидать, я сейчас не хвалю эту программу), потому что любой сложности "планчик" для универа научиться делать в нём можно за несколько дней и, в итоге, за несколько кликов вытащить из него фасады, разрезы, развёртки, вывести грамотно на печать и тд. Минусы - в данной проге (по сравнению со следующими советами) отвратительное и невнятное моделирование.
2. Компас в принципе хорош, но его буквально считанные недели назад переиздали, написав, как говорят, заново. Компас преобразился, стал серьёзнее, но сырой и много ещё чего придётся исправлять. По новой версии нет учебных материалов, а старую уже учить нет смысла.
3. Самый большой вклад в будущее даст AutoCAD (в идеале версии Architecture), так как это эталон для всех остальных программ (кто бы что не говорил) и он даст ту базу, с которой легко будет, опять же "с наскока", постигать любые другие продукты. А главное - он дисциплинирует. Но, если подойти правильно, дочерта нужно учить (кроме тех кто способен в активном режиме читать инструкцию командной строки, ведь поговорку "русский инструкцию не читает" никто пока не отменял ;) ) Плюсы - востребован на рынке и прокачивает дисциплину (если пойти дальше в программирование - даёт практически неограниченные способности, но к моему сожалению, остаюсь практически в одиночестве, минусы - следующий совет).
4. Всё более востребован - Revit, особенно лёгок после "автокада" понятное дело, но выше "порог вхождения" и учитывая качество образования в наших универах - легко забуксовать из-за обилия настроек и уйти в уныние. Зато, если взять себя в руки, и не побояться - пойдёшь в ногу со временем, но " с наскоку" не получится ничего.

В любом случае, нужен хороший и структурированный учебный материал. А главное - не устаревший и не мертворождённый, как подавляющее большинство на том же "ютубе". А лучше всего - хороший наставник. Если нужны материалы - или место где можно подтянуть навыки - пиши, помогу.

Все это делает стим. Заканчивайте пиратить игра и так копейки стоит.
А по факту чтобы такое сделать нужно примерно следующее:
1) Тут можно конечно извратиться но в абсолютно любом случае. Вам нужно будет писать плагин для сервера на с++ в котором каким либо образом осуществлять коннект с клиентом к примеру по сокетам. С клиентской стороны писать опять же писать плагин все также на с++ для игры и при этом отключать верефикацию сертификата или получить его у valve чтобы плагин заработал на клиенте. Промежуточное звено в виде веб сервера с простым скриптом и БД для хранения и верефикации токенов Дальше обвязывать все это друг с другом что то типа:
-запуск игры из лаунчера(получение токена от промежуточного сервера) и передача его в игру
-игра запустилась и приняла плагином движка этот токен, коннект к серверу и передача на него этого токена.
-клиент подключился к серверу и принял токен. Сервер делает верефикацию полученного токена от клиента на промежуточном сервере и по результату разрешает вход в игру или дисконектит с сервера.
2) Свой античит даже близко недостающий функционалом до VAC у вас не получится, на это во первых тратят огромные деньги, во вторых нет исходников игры чтобы понимать чем пользуется чит. В третьих сама ОС
антивирус забракует такую подозрительную активность от левого процесса в система посчитав ваш лаунчер вирусом.
3) Тут делать как угодно можно, начиная от скриншотов самим лаунчером, заканчивая тем что их может делать плагин движка.
4) Зависит от функционала.