Конечно в курсе. Я больше 7 лет исключительно на ассемблере писал.
а если на машинном коде писать сразу так вобще!
Что значит «так вобще»? Производительность возрастёт? Памяти меньше занимать будет?
Не смешите. Ассемблер, по сути, является «литературной» записью машинного кода.
Были времена, когда приходилось и напрямую машинный код писать/читать - но не вижу в этом ничего крутого.
держу пари, вы сами все возможности не знаете.
Я говорил не о тех возможностях, которые уже предоставляет движок, а о возможностях, которые он не предоставляет.
максимальная производительность чего? с каких пор механнике игры (геймплею) требуется максимальная роизводительность при мощностях современных процессоров? можете описать пример? а то боюсь разговаривать, не понимая о чем речь невозможно. или это какая то другая максимальная производительность?
Производительность на мобильных устройствах весьма критична. И примеров миллионы. Прямо сейчас переписываю систему поиска оптимального пути/логики выбора целей/перемещения больших групп зомбей/и т.п. за двумя предыдущими программистами (на что заказчиком было потрачено пол года времени и несколько тысяч долларов). Когда игра попала ко мне, в неё было невозможно играть: на мощном десктопе (десктопе, а не тем более на каком-нибудь двухлетнем планшете!) выдавалось примерно 3 FPS (не только из-за поиска пути, там ещё много «творчества» было - очень медленный световой движок, например). По большей части производительность зависит от архитектуры/правильно выбранных алгоритмов, но для мобилок нередко приходится вообще по максимуму выжимать. Если вам нужен клон Angry Birds, Flappy Bird или 2048, то, конечно, вообще без разницы (только не понятно, зачем там вообще такие движки - хватит и какого-нибудь мелкого конструктора/движка). Однако, не только такие игры делаются, есть и посложнее. Если мне память не изменяет, за последние пять лет у меня такая простая игра была только одна. Игр, где вообще не требовалась производительность - тоже не особо много, на пальцах одной руки можно пересчитать. Все остальные так или иначе приходилось в значительной степени оптимизировать (в основном - под Android/iOS) - где-то по памяти/текстурам, где-то по CPU, где-то по работе с файлами, где-то ещё что-нибудь. Если вам не требовалась максимальная производительность, то это не значит, что это не потребуется никому и никогда.
для некоторых это проще, чем наследование, и темплейты классов и переменных, виртуальные функции и перегрузки (хотя для некоторых и нет). и такие вещи есть не только в уе.
Естественно для новичка проще. А для профи скорее будет ровно наоборот - проще написать строку кода.
как и я, автор, а так же 99.5% программистов, которые все таки довели свои проекты до конца. причем не на с++, а на каком нибудь "медленном" delphi,java,c#,(вставьте свой вариант).
Мой первоначальный посыл - чистый язык даёт больше возможностей, чем визуальная среда программирования. То, что c++ даёт максимальную производительность - это просто бонус (хотя в некоторых случаях он может быть критичным). Я не призывал не использовать blueprint или, тем более, писать всё исключительно на c++ (безотносительно движка). Я на c/c++ пишу настолько редко, насколько могу, но иногда всё же приходится брать и выносить критичный код в библиотеку и использовать её из скриптов/etc.
А почему я не сказал «да, делайте всё на blueprint» - перспектива. Если топикстартер будет заниматься серёзно разработкой игр (на что указывает «для инди-студии и карьеры», то рано или поздно придётся выйти за рамки «конструктора», а для UE в этом случае придётся использовать c++. И если человек абсолютно не знаком с ними, то получится большая проблема, так как хоть сколько-нибудь адекватно изучить «плюсы» за короткое время не получится. В аналогичной ситуации с шарпом разобраться будет намного проще.
многие люди не зная ни одного языка программирования отлично разрабатывают логику без использования с++ в уе.
Я не утверждал, что с помощью blueprint ничего невозможно сделать. А тем более, логику писать или механику, где не требуется максимальная производительность, - да пожалуйста. Речь шла об вообще всех возможностях, которые даёт с++. Хотя вы правы в том, что начинающим инди, чтобы «выдавать вполне годные инди поделки» вполне может хватать и исключительно blueprint'а.
Дмитрий Макаров: Можно и быстрее бросить курить. У меня после более чем 12 лет стажа (насколько помню, в конце выходило чуть больше пачки в день) «ломка» была три дня. На четвёртый день проснулся и понял, что желания курить нет абсолютно - оно просто пропало и с тех пор (больше 10 лет) не появлялось.
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>
Конечно в курсе. Я больше 7 лет исключительно на ассемблере писал.
Что значит «так вобще»? Производительность возрастёт? Памяти меньше занимать будет?
Не смешите. Ассемблер, по сути, является «литературной» записью машинного кода.
Были времена, когда приходилось и напрямую машинный код писать/читать - но не вижу в этом ничего крутого.
Я говорил не о тех возможностях, которые уже предоставляет движок, а о возможностях, которые он не предоставляет.
Производительность на мобильных устройствах весьма критична. И примеров миллионы. Прямо сейчас переписываю систему поиска оптимального пути/логики выбора целей/перемещения больших групп зомбей/и т.п. за двумя предыдущими программистами (на что заказчиком было потрачено пол года времени и несколько тысяч долларов). Когда игра попала ко мне, в неё было невозможно играть: на мощном десктопе (десктопе, а не тем более на каком-нибудь двухлетнем планшете!) выдавалось примерно 3 FPS (не только из-за поиска пути, там ещё много «творчества» было - очень медленный световой движок, например). По большей части производительность зависит от архитектуры/правильно выбранных алгоритмов, но для мобилок нередко приходится вообще по максимуму выжимать. Если вам нужен клон Angry Birds, Flappy Bird или 2048, то, конечно, вообще без разницы (только не понятно, зачем там вообще такие движки - хватит и какого-нибудь мелкого конструктора/движка). Однако, не только такие игры делаются, есть и посложнее. Если мне память не изменяет, за последние пять лет у меня такая простая игра была только одна. Игр, где вообще не требовалась производительность - тоже не особо много, на пальцах одной руки можно пересчитать. Все остальные так или иначе приходилось в значительной степени оптимизировать (в основном - под Android/iOS) - где-то по памяти/текстурам, где-то по CPU, где-то по работе с файлами, где-то ещё что-нибудь. Если вам не требовалась максимальная производительность, то это не значит, что это не потребуется никому и никогда.
Естественно для новичка проще. А для профи скорее будет ровно наоборот - проще написать строку кода.
Мой первоначальный посыл - чистый язык даёт больше возможностей, чем визуальная среда программирования. То, что c++ даёт максимальную производительность - это просто бонус (хотя в некоторых случаях он может быть критичным). Я не призывал не использовать blueprint или, тем более, писать всё исключительно на c++ (безотносительно движка). Я на c/c++ пишу настолько редко, насколько могу, но иногда всё же приходится брать и выносить критичный код в библиотеку и использовать её из скриптов/etc.
А почему я не сказал «да, делайте всё на blueprint» - перспектива. Если топикстартер будет заниматься серёзно разработкой игр (на что указывает «для инди-студии и карьеры», то рано или поздно придётся выйти за рамки «конструктора», а для UE в этом случае придётся использовать c++. И если человек абсолютно не знаком с ними, то получится большая проблема, так как хоть сколько-нибудь адекватно изучить «плюсы» за короткое время не получится. В аналогичной ситуации с шарпом разобраться будет намного проще.