Airat1995: это напрямую зависит от правообладателя. Nintendo вполне могут "зарубить" и после в суд подать - даже на бесплатный проект. По закону, нельзя использовать персонажей/вселенную/и т.д., если не получили разрешения от правообладателя, независимо от ваших целей и желания выгоды.
Михаил Снэ Бьёрн Палагин: первый вопрос: не нужно бросаться в бой и рисковать деньгами. Чтобы хотя бы просто довести проект до конца, уже нужен опыт. Соответственно, для начала - энтузиазм и совмещение с основной работой. Какой-нибудь достаточно маленький проект, чтобы, во-первых, на практике узнать весь процесс, "от и до" и, во-вторых, научиться работать в команде.
Второй вопрос: зависит от объёма графики, финансовых возможностей и непосредственно от исполнителей. Для начала один художник и один 3d. В моём последнем проекте (не моём, а том, в котором я участвовал - работал в студии, вся команда игры человек 7) был один 3d (включая текстурирование - модели не сложные) и два-три художника (один концепты, другой - на интерфейсах, векторе, ещё один - вся остальная графика). Предыдущий проект (другая студия, очень много графики) - там было два 3d и человек 5 просто художников (плюс, один из 3d художников подключался к ним) (концепты, текстуры, пост-обработка).
Начинайте с малого, а дальше сами поймёте, как вам будет лучше.
Третий вопрос: по Unity - да, мог бы, но не прямо сейчас (тем не менее, начать можно с официальной документации и официальных уроков). Хотя сперва нужно ознакомиться с C#. Тут одна из наиболее удачных книг "Шилдт Г. - C# 4.0 полное руководство" (ну, наверняка уже более поздние издания были)... Сам я программист и в прошлом также занимался дизайном, но в части гейм-дизайна мой опыт весьма поверхностен, а потому не рискну что-то советовать в этом направлении - лучше спросить у профессионалов.
Coderast: не нужно сравнивать с профессиональными студиями/разработчиками. Хотя Unreal мощнее, при этом он и сложнее. Blueprint - скорее вспомогательное средство, а не принципиальная замена программированию. Многие вещи быстрее написать кодом, чем сделать в визуальном редакторе. А какие-то возможно сделать только кодом. Ну и огромнейший магазин Unity также будет очень полезным для начинающей команды.
Михаил Снэ Бьёрн Палагин: Да, Unity достаточно популярный движок и вакансии по нему не так уж и редки.
Что касается создания игры, то тут всё гораздо сложнее. Во-первых, хочу вас предостеречь: не нужно думать, что у вас всё получится с первого раза. И не нужно думать, что ваша первая выпущенная игра заработает миллионы. Или вообще хоть что-нибудь заработает. Сейчас для успешного издания коммерческой игры нужны весьма немалые средства - как на разработку, так и на продвижение.
Чтобы просто завершить игру, также нужно приложить весьма немало усилий. Реалии таковы, что если нет хорошего бюджета (относительно простые игры запросто могут потянуть на несколько /даже несколько десятков/ миллионов), то собрать хорошую (ответственную) команду шансов почти нет. А это значит, что, скорее всего, начнёте с одними людьми, а закончите с другими. При разработке наверняка столкнётесь со множеством трудностей - возможно, и диздок придётся переписывать, а возможно, что и не однократно. И с каждым днём энтузиазм команды будет становиться всё меньше и меньше. Также нужно понимать, что все предполагаемые вами сроки могут затянуться в несколько раз. Моя практика такова, что в среднем на разработку одной игры уходило примерно полтора года (но это индивидуально и во многом зависит от самой игры - есть и такие игры, которые можно сделать за неделю или месяц). А бывало и такое, что половину графики перерисовывали с нуля три раза. Хотя таких вещей желательно избегать, они случаются и нужно быть готовым к такому. Но у вас всё может получиться - это не фантастика и всё вполне реально.
Если ваша роль в проекте будет программист + гейм-дизайнер, то при завершенном диздоке сценарий может быть, например, таким. Для начала вам можно обойтись и без 3d-моделлера - найти в интернете бесплатные модели и временно использовать их, просто для разработки прототипа и изучения игровой механики. На этом этапе можно понять, хорошая ли идея, интересно ли будет играть и т.п. Далее, вам нужен концепт-арт. Возможно, что вы, как дизайнер, сами сделаете это, либо найдёте художника. После подбора стиля и разработки концепт-арта уже можете искать 3д моделлера. Звуки/музыку можно отдать на аутсорс ближе к концу разработки (а в процессе разработки также можно использовать временные звуки/музыку.
В идеале, конечно, сначала концепт-арт (собственно, какая-то его часть должна входить в диздок), затем прототип, но нужно рассчитать так, чтобы художник не оказался "не у дел" на время разработки прототипа. Собственно, это касается и любого другого члена команды - чем дольше ему нечего делать, тем больше шансов угасания интереса к проекту.
Михаил Снэ Бьёрн Палагин: От этого зависит, какой движок выбрать. Например, основной язык в Unreal Engine - это C++, а в Unity - C#. Если у вас нет опыта ни в том, ни в другом, то логично будет выбрать тот, который учить проще. Соответственно, вам лучше выбрать Unity и C#.
Про форки - верно. Но в оригинале речь идёт об реестре программ/проектов/библиотек/фреймворков, которые можно подключать в свои проекты. В данном случае "производный" не подходит. Я бы сказал, он скорее зависящий.
"Ловушка" - да, встречал такой перевод. Возможно, в моём случае будет наиболее подходящий. Спасибо.
Спасибо за ответ. Здесь имеется в виду зависимость одного проекта от другого. Как пример - upstream проект является библиотекой, а downstream проект использует эту библиотеку.
Да, это просто погрешность автоматического перевода. На английской версии сайта список:
Contain:
1 x Android Mini PC
1 x Charger
1 x Remote control
1 x HDMI Cable
1 xAV cable
1 x User Manual
просто пропущен пробел, потому перевелось некорректно.
Спасибо за совет! В моём случае это оказалось именно то, что нужно. Наконец-то, после множества лет, могу писать на английском без гугл-переводчика.
Также есть официальная программа под iOS/Android (Полиглот 16 Дмитрия Петрова). Не проверял iOS-версию, но в Android-версии есть небольшие баги, что, впрочем, не мешает ей пользоваться.
Наиболее известные формулы (из Wiki):
В цветовых пространствах YUV и YIQ используемые в PAL и NTSC яркость Y' вычисляется следующим образом:<b>
Y' = 0.299 R + 0.587 G + 0.114 B</b>
Для учёта особенностей восприятия изображения человеческим глазом (чувствительность к зелёному и синему цвету) в модели HDTV используют другие коэффициенты:<b>
Y' = 0.2126 R + 0.7152 G + 0.0722 B</b>