Игровой движок для инди-студии и карьеры, что выбрать?
Всем доброго времени суток.Заранее пишу, что текста будет много и жду вразумительных ответов от людей которые действительно понимают что пишут и почему дают совет.
И так начнем, я уже создавал тему раннее, но не получил нормального ответа. Мне 28 лет, я дизайнер в рекламном агентстве, рисую всякие флаера, буклеты, делаю логотипы и т.п., не хочу обидеть других дизайнеров, но я начал понимать что это не мое. Я давно мечтал уйти в индустрию геймдева, не знаю правда почему не решался и почему не ушел уже давно, но вот на данный момент решил окончательно забросить дизайн и идти только к своей мечте. Расклад такой, так как мне 28 лет, я поставил для себя цель, до 30 лет, то есть за 2 года изучить игровой движок, хотя бы процентов на 60-70, да многие скажут это невозможно и т.п., но я брошу все дела и сделаю полное упорство на изучение именно движка. В планах после изучения, создать свою инди-студию и делать игру. Игра уже есть, ну точнее диздок по игре готов на 50-60 процентов. План был таков, что я делаю диздок, изучаю выбранный движок, далее ищу 3д-моделера, худождника и совместными силами мы будем пытаться воплотить игру из диздока.
Теперь самая суть вопроса. Какой же игровой движок можно выбрать из мною предоставленных, а это: Unreal Engine 4, Unity3D, CryEngine, Blender. Отметил только эти, так как имею расположение что данные движки спокойно справляются с играми по типу ММО, да и сетевая часть у движков хорошо проработана. Но стоит и другой вопрос, но сколько я знаю, UE4 стал бесплатным и лишь после того как игра привысит 3000$ я буду должен платить им по 5% от прибыли. Вроде приятная плюшка. На счет Unity3D и CryEngine честно вообще нечего не знаю, хотелось бы услышать от Вас что то вразумительное. Про Blender не буду говорить, так как все прекрасно знают, что он полностью бесплатен, но и далеко на нем вроде не уедешь. Так что вроде остаются только три гиганта.
Так что, что же лучше выбрать инди-студии, чтобы в дальнейшем не обжечься, не прогореть из-за движка. Да и самое главное, что даже если у меня не получиться сделать игру, чтобы потраченные на изучения движка 2 года, не ушли в пустую, чтобы с этими знаниями я смог устроится на работу в гейм индустрию и дальше продолжать изучать движок и наслаждаться любимым делом. В общем вот такой вот рассказ :) Жду ответов уважаемые коллеги...
Михаил Снэ Бьёрн Палагин: От этого зависит, какой движок выбрать. Например, основной язык в Unreal Engine - это C++, а в Unity - C#. Если у вас нет опыта ни в том, ни в другом, то логично будет выбрать тот, который учить проще. Соответственно, вам лучше выбрать Unity и C#.
Дмитрий: Ок, спасибо. Я тоже сейчас сидел и читал плюсы и минусы обоих движков и что то для моей цели я присмотрел именно юньку. Но вот теперь другой вопрос, который так же описан в моей посте. То есть я беру движок, начинаю изучать весь его функционал, изучаю С# и все? Далее имея в штате 3д моделера и художника я уже смогу на движке делать то что написано у меня в диздок, я прав? И такой вопрос, если вдруг не получится что то с игрой, я смогу имея знания в юньке и c# устроится в гейм студию и т.п.?
Только в случае, если в гейм студии используется юнька. Unreal Engine на много распространеннее, на ней, например, сделаны Mass Effect и Portal. А на Unity из серьезных только The Forest и StarDrive 2 ( насчет второй могу ошибаться ).
К тому же, в Unreal Engine есть такая штука, как Blueprint - визуальное программирование. Для тех, кто не знает языки. Но все же C++ там желательно знать.
Зная C# или C++ на уровне написания игр можно, по моему скромному мнению, устроится не только в гейм дев, имхо.
Михаил Снэ Бьёрн Палагин: Да, Unity достаточно популярный движок и вакансии по нему не так уж и редки.
Что касается создания игры, то тут всё гораздо сложнее. Во-первых, хочу вас предостеречь: не нужно думать, что у вас всё получится с первого раза. И не нужно думать, что ваша первая выпущенная игра заработает миллионы. Или вообще хоть что-нибудь заработает. Сейчас для успешного издания коммерческой игры нужны весьма немалые средства - как на разработку, так и на продвижение.
Чтобы просто завершить игру, также нужно приложить весьма немало усилий. Реалии таковы, что если нет хорошего бюджета (относительно простые игры запросто могут потянуть на несколько /даже несколько десятков/ миллионов), то собрать хорошую (ответственную) команду шансов почти нет. А это значит, что, скорее всего, начнёте с одними людьми, а закончите с другими. При разработке наверняка столкнётесь со множеством трудностей - возможно, и диздок придётся переписывать, а возможно, что и не однократно. И с каждым днём энтузиазм команды будет становиться всё меньше и меньше. Также нужно понимать, что все предполагаемые вами сроки могут затянуться в несколько раз. Моя практика такова, что в среднем на разработку одной игры уходило примерно полтора года (но это индивидуально и во многом зависит от самой игры - есть и такие игры, которые можно сделать за неделю или месяц). А бывало и такое, что половину графики перерисовывали с нуля три раза. Хотя таких вещей желательно избегать, они случаются и нужно быть готовым к такому. Но у вас всё может получиться - это не фантастика и всё вполне реально.
Если ваша роль в проекте будет программист + гейм-дизайнер, то при завершенном диздоке сценарий может быть, например, таким. Для начала вам можно обойтись и без 3d-моделлера - найти в интернете бесплатные модели и временно использовать их, просто для разработки прототипа и изучения игровой механики. На этом этапе можно понять, хорошая ли идея, интересно ли будет играть и т.п. Далее, вам нужен концепт-арт. Возможно, что вы, как дизайнер, сами сделаете это, либо найдёте художника. После подбора стиля и разработки концепт-арта уже можете искать 3д моделлера. Звуки/музыку можно отдать на аутсорс ближе к концу разработки (а в процессе разработки также можно использовать временные звуки/музыку.
В идеале, конечно, сначала концепт-арт (собственно, какая-то его часть должна входить в диздок), затем прототип, но нужно рассчитать так, чтобы художник не оказался "не у дел" на время разработки прототипа. Собственно, это касается и любого другого члена команды - чем дольше ему нечего делать, тем больше шансов угасания интереса к проекту.
Нет, блюпринт лишь помощник. Понимаете, вы определитесь, вы хотите быть тем, кто управляет созданием игрой, тем кто пишет код, или тем кто рисует? В серьезном гейм деве этим занимаются разные люди.
Дмитрий: Спасибо за хорошо развернутый ответ. Теперь пару вопросов по Вашему ответу. Первый вопрос - игра будет ММО, что то в стиле Crash Racing, но только с сетевой составляющей, прокачкой уровней, скиллов и оружия. Игра будет Ф2П, но со своим внутри игровым магазином, который однозначно на баланс в игре влиять не будет, но и в тоже время сможет кормить студию и держать на плаву сервера и т.п. Это все практически расписано в диз-доке. Теперь суть вопроса, как Вы считаете где и на каких условиях можно искать людей в команду, искать ли энтузиастов или же брать кредит и нанимать уже людей как на работу?
Второй вопрос - по графике, в игре будет графики в стиле World of Warcraft, Crowfall и т.п., то есть по графике она будет с минимальными требованиями. Дело не в том что лень делать крутой графон, а в том что мне нравится данный стиль. Как Вы считаете, хватит ли одного художника и 3д моделера для всего этого, либо надо искать и художника по текстурам и аниматора и еще кого то там :(
Вопрос третий - Если я все таки останавлюсь на юньке и с#, Вы смогли быть дать рекомендации с чего начинать, что изучать, именно чтобы в итоги придти к своей цели: программист + гейм-дизайнер?
Coderast: не нужно сравнивать с профессиональными студиями/разработчиками. Хотя Unreal мощнее, при этом он и сложнее. Blueprint - скорее вспомогательное средство, а не принципиальная замена программированию. Многие вещи быстрее написать кодом, чем сделать в визуальном редакторе. А какие-то возможно сделать только кодом. Ну и огромнейший магазин Unity также будет очень полезным для начинающей команды.
Coderast: Ну так я и написал, я хочу быть тем кто собирает игру из того что мне даст 3д-моделер, аниматор и т.п.
Да возможно совместить программист С# (unity) или c++(ue4) + гейм-дизайнер. На данный момент я лишь определяюсь какой движок и ЯП выбрать для осуществления своей мечты. Я пока не собираюсь искать работу себе в гейм-деве, а лишь потратить 2 года и изучить досканально один из движок и изучить один из ЯП. А далее делать игру по своему диздоку, а вот уже если не получится по каким либо причинам, быть уже уверенным что я не просто так потратил на изучение 2 года и могу найти себе работу в которой я буду совершенствоваться дальше.
Михаил Снэ Бьёрн Палагин: первый вопрос: не нужно бросаться в бой и рисковать деньгами. Чтобы хотя бы просто довести проект до конца, уже нужен опыт. Соответственно, для начала - энтузиазм и совмещение с основной работой. Какой-нибудь достаточно маленький проект, чтобы, во-первых, на практике узнать весь процесс, "от и до" и, во-вторых, научиться работать в команде.
Второй вопрос: зависит от объёма графики, финансовых возможностей и непосредственно от исполнителей. Для начала один художник и один 3d. В моём последнем проекте (не моём, а том, в котором я участвовал - работал в студии, вся команда игры человек 7) был один 3d (включая текстурирование - модели не сложные) и два-три художника (один концепты, другой - на интерфейсах, векторе, ещё один - вся остальная графика). Предыдущий проект (другая студия, очень много графики) - там было два 3d и человек 5 просто художников (плюс, один из 3d художников подключался к ним) (концепты, текстуры, пост-обработка).
Начинайте с малого, а дальше сами поймёте, как вам будет лучше.
Третий вопрос: по Unity - да, мог бы, но не прямо сейчас (тем не менее, начать можно с официальной документации и официальных уроков). Хотя сперва нужно ознакомиться с C#. Тут одна из наиболее удачных книг "Шилдт Г. - C# 4.0 полное руководство" (ну, наверняка уже более поздние издания были)... Сам я программист и в прошлом также занимался дизайном, но в части гейм-дизайна мой опыт весьма поверхностен, а потому не рискну что-то советовать в этом направлении - лучше спросить у профессионалов.
Дмитрий: Честно сказать, как раз и ожидал таких ответов. Они полностью сходятся с моими мыслями. Как я могу позже с Вами связаться, ну или Вы со мной, когда будет у Вас свободное время. Мой ВК https://vk.com/mp.ven000mus и почта ven000mus@gmail.com
Спасибо за потраченное время.
Дмитрий Дмитрий
Михаил Снэ Бьёрн Палагин: Например, основной язык в Unreal Engine - это C++, а в Unity - C#. Если у вас нет опыта ни в том, ни в другом, то логично будет выбрать тот, который учить проще.
вобще то нелогично... хотя бы из за этого: основной язык НА КОТОРОМ исходники УЕ - с++ язык для разработки blueprint / c++ (имено в такой последовательности). многие люди не зная ни одного языка программирования отлично разрабатывают логику без использования с++ в уе. как то им ничего не мешало создать клиент серверное приложение с созданием аккаунта, классов игроков, мобов, моделей, текстур.... чето странно люди не зная языка программирования вполне неплохо в сжатые сроки выдают вполне годные инди поделки...
"а что я могу не зная C++ делать игру и ее механику полностью на блюпринте? " - да. спагетти конечно ещё те получаются если механника навороченная... но делать можно абсолютно то же самое что и кодом. но в .нити есть плагины для такого же визуального программирования.
"
Coderast Coderast
Нет, блюпринт лишь помощник." - нет блюпринт - это шаблонное управление, под которым лежит тот же с++ код и доступ к тем же функциям.
однако в чем согласен интуитивно юнити ближе к инди студиям потому, что написан в соновном для них и в нем попроще разбираться основной массе (зависит от талантов и хотения человека).
но на первые проекты я даже его бы не рекомендовал. есть множество ругих движков с предоставляемой и говтовой клиент-серверной частью, анимацией, текстурами моделями, примитивной комбат системой, спелл-каст, левел эдитором, начальными моделями, системой раздачи квестов.
интересно вы понимаете сколько времени уйдет на реализацию этих вещей в выбранных вами движках? вы же не думаете что эти движки позволит вам перейти к геймплею сразу?
так же судя по тому что вы даже не намекнули на это - рискну предположить, что через кучу подготовительных этапов вы попросту ещё не прошли.
ответ на суть Вашего вопроса: ни один из тех, что вы выбрали. - но это только мое мнение на основе вашего вопроса и предистории к нему.
многие люди не зная ни одного языка программирования отлично разрабатывают логику без использования с++ в уе.
Я не утверждал, что с помощью blueprint ничего невозможно сделать. А тем более, логику писать или механику, где не требуется максимальная производительность, - да пожалуйста. Речь шла об вообще всех возможностях, которые даёт с++. Хотя вы правы в том, что начинающим инди, чтобы «выдавать вполне годные инди поделки» вполне может хватать и исключительно blueprint'а.
Дмитрий: "где не требуется максимальная производительность"
"вообще всех возможностях, которые даёт с++"
"максимальная производительность", "все возможности языка с++" - вы ведь в курсе, что асемблер быстрее? а если на машинном коде писать сразу так вобще! только быстрее - о чем речь: о человеко-часах или кол-ве операций в секунду? - опять абстрактная вещь. обсуждаем, идеально пишушего код, человека в вакууме при ответе на вопрос какой движок лучше выбрать автору?
что за "все возможности"? для чего они автору? как они ему помогут реализовать то, что он хочет? он точно будет использовать "ВСЕ ВОЗМОЖНОСТИ"? вы уверены?
держу пари, вы сами все возможности не знаете.
как и я, автор, а так же 99.5% программистов, которые все таки довели свои проекты до конца. причем не на с++, а на каком нибудь "медленном" delphi,java,c#,(вставьте свой вариант).
максимальная производительность чего? с каких пор механнике игры (геймплею) требуется максимальная роизводительность при мощностях современных процессоров? можете описать пример? а то боюсь разговаривать, не понимая о чем речь невозможно. или это какая то другая максимальная производительность?
"Я не утверждал, что с помощью blueprint ничего невозможно сделать." - да не утверждали. это я хватанул. диалог был таким:
"
Михаил Снэ Бьёрн Палагин Михаил Снэ Бьёрн Палагин:
а что я могу не зная C++ делать игру и ее механику полностью на блюпринте?
Написано 17 мая
Ответить
Coderast Coderast
Нет, блюпринт лишь помощник. ...
Написано 17 мая
"
что несколько неверно. полноценную игру с достаточно сложной механникой геймплея, аи, систем меню, спавна монстров, функций, макросов, евентов, и прочих взаимодействий игровых объектов с гг по определенным правилам от начала до конца + кучи других задач - можно. для некоторых это проще, чем наследование, и темплейты классов и переменных, виртуальные функции и перегрузки (хотя для некоторых и нет). и такие вещи есть не только в уе. В юнити кстати помимо С# есть скриптовый язык.
что я собственно и (по)пытался отметить. ничего более.
у этих методов правда недостаток - через 2 года автор мастер блюпринтов и скриптового юнити может быть не востребован в геймдеве в кое какой стране.
Конечно в курсе. Я больше 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++. И если человек абсолютно не знаком с ними, то получится большая проблема, так как хоть сколько-нибудь адекватно изучить «плюсы» за короткое время не получится. В аналогичной ситуации с шарпом разобраться будет намного проще.
Дмитрий:
Я говорил не о тех возможностях, которые уже предоставляет движок, а о возможностях, которые он не предоставляет.
значит я просто не понял что речь шла о движке а не о языке в целом из сказанного... Дмитрий: " Речь шла об вообще всех возможностях, которые даёт с++. "
это все не так важно.
перечитал - убедили - перспектива блюпринтов в серьезной студии - мапмейкер, скрипт-программер, гейм-дизигнер (хорошо, если главный);
если цель "карьеры в геймдеве" более важна, чем движок, инди-студия и создать законченный проект (пусть он и будет простеньким) - соглашусь. в этом случае да, нет возражений.
исключительно мои мысли: мне решение в 28 лет начать фактически с 0 и уйти в программинг кажется несколько импульсивным.
сильно не уверен, что в "одной большой стране" (хз откуда автор родом - если с украины, там получше вроде как слышал) он действительно сможет "изучать движок и наслаждаться любимым делом" (вероятно автор в скором времени откажется от этой гиблой затеи, если уже не отказался).
(на что заказчиком было потрачено пол года времени и несколько тысяч долларов). - поверьте после миллиардного проекта (в баксах) в некоторых сферах бизнесса и уже полутора лет допиливания процедур, гораздо проще относишься к просранным срокам в геймдеве.))) хотя это я такой раздолбай - если нормально задачи не ставить и не прислушиваться к советам программистов выполняющих эту задачу... я не особо парюсь о результатах. и все же.. слышать "выдавалось примерно 3 FPS" - несколько странно. это российская компания? во первых уже хотя бы потому, что 3 фпса будут заметны сразу. (только не думайте, что я не верю - когда я работал фпс были норм, но вот с идеями и "интересным геймплеем и основными фишками" был полный швах).
Мне нет. только под PC либо ps3-4. там все стандартно и давно выверено. что бы загубить фпс там надо просто не думая код писать, либо придумать, что то настолько навороченное, в чем в реальности мало кто сможет разобраться и оценить.
Тут правда вопросик возникает - а оно надо вобще, так напрягаться то, если вам приходиться все это дело переписывать? (оставлю этот ответ на веру, ибо у меня на этот счет есть свои менеджерские взгляды).
zac02: Хорошо, немного подробнее расскажу о ситуации.
Я не имел в виду, что сумма огромная или что-то такое. Это не компания, а просто один человек из небогатой европейской страны, сам он художник и гейм-дизайнер (это хобби, а его постоянная работа с IT никак не связана), решивший выпустить игру, которая сейчас находится в раннем доступе в Стиме.
Первый программист был из Украины, но скиллы у него были довольно слабые и через какое-то время был уволен. Второй программист был из Канады. Он посмотрел код первого программиста и, несмотря на возражения, сказал "я всё перепишу заново, бесплатно", начал всё переделывать (в принципе, я видел код первого программиста и понимаю, почему он решил это сделать).
Через несколько месяцев его энтузиазм иссяк и он «слился». Последние его разработки были как раз связаны со световым движком и в Стиме оказалась та самая версия с 3 fps. Не представляю, зачем её залили в таком виде и проверяли ли вообще перед закачиванием (сейчас я тестирую своими силами перед отправкой издателю). Но факт такой. Для меня это тоже непривычно: после Алавара, Kongregate, BFG, Zylom и множества других крупных и небольших издателей, которые всегда проводят тщательное тестирование (хотя мелкие российские издатели довольно часто «халтурили», да и крупные бывало фейлили при релизе локализованных версий, но это скорее исключения). И обычно не было релиза, пока не будут закрыты все баги. С изданием в Early Access я до этого не сталкивался и огромный список критичных багов, на странице сообщества игры в Стиме, был для меня неожиданностью. Хотя большинство из них я пофиксил в первые же дни начала работы, ещё до заглядывания в Стим - настолько они очевидны были.
Насколько знаю, перед вторым программером рейтинг в Стиме был около 60-70% положительных отзывов и огромное количество установок. Не в курсе подробностей, но уже при мне, за прошлый месяц, с распродажной ценой около 6 центов, игра заработала несколько тысяч долларов.
В тот момент, когда я подключился к проекту, игру заминусовали до примерно 20-30% за кучу багов и тормоза. У человека обязательства перед издателем, он не хочет потерять его доверие, наработанное за несколько лет до этого. Неприятная ситуация.
Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps. После сделал множество других фиксов и исправлений. Рейтинг через несколько недель восстановился, а сейчас составляет 80%. Ничего сверхнавороченного не было - игра 2d, вид сверху, помещения, толпы зомби, крафт и т.п. Но из-за недостаточных скиллов программеров использовались сомнительные решения, из-за которых возникали большие тормоза. В световом движке, например, один из источников тормозов - создание размытой тени (для ambient occlusion) через многократное рисование почти полностью прозрачного спрайта. Я использовал шейдеры, но тут же выяснилось, что не на всех машинах игроков они работают (отсутствует необходимый рантайм directx на некоторых версиях Windows). В итоге сделал два варианта: шейдеры по умолчанию, а у кого они не работают, всё рисуется программно, но с кучей оптимизаций (ну а сложные полноэкранные эффекты просто будут отсутствовать). Иногда чуть менее красиво, медленнее, но работает.
Ещё один уже упомянутый источник тормозов - поиск цели для атаки при спавне большого количества зомби. Тут пришлось перейти на нативный код, а позже полностью начать переписывать всю систему. Сейчас как раз заканчиваю её.
По некоторым причинам эта игра выйдет в минимальном виде только на PC, в Стиме, а на мобилках новичку запороть всё гораздо проще. Перешел на фриланс примерно год-полтора назад и за это время ко мне не раз обращались с просьбой оптимизации игр на мобилках: скиллов сделать игру у людей хватает, на десктопах всё прекрасно работает, а на планшетах и телефонах - тормоза да постоянные вылеты. Вот и приходится - где-то нативный код, где-то шейдеры, где-то кучу графики оптимизировать и т.д.
Дмитрий: "Я не имел в виду, что сумма огромная или что-то такое." - а никто про это не говорил. просто непонятно причина, по которой упомянули сумму и сроки. тем более из последующего пояснения видно, что они тут "никаким боком не при чем". тем более я специально намекнул "только не думайте, что я не верю " - что не требовало объяснений. Дмитрий: Это не компания, а просто один человек из небогатой европейской страны. У человека обязательства перед издателем, он не хочет потерять его доверие.
весьма странное поведение для человека, который "не хочет потерять доверие". забавно, что ведет он себя по глупому. тем более он из европы.
тем более о чем речь если человек, Дмитрий: "решивший выпустить игру".
при чем тут Дмитрий: "У человека обязательства перед издателем, он не хочет потерять его доверие, наработанное за несколько лет до этого"....
чет я перестал понимать о чем речь. выпустить значит сделать игру? просто на мой взгляд выпустить включает в себя понятия сделать, и издать. Дмитрий: Первый программист был из Украины, но скиллы у него были довольно слабые и через какое-то время был уволен... Насколько знаю, перед вторым программером рейтинг в Стиме был около 60-70% положительных отзывов и огромное количество установок
по моему этот человек, не желающий терять доверие какого то там издателя, немного не своим делом занялся. 60-70% вполне неплохой результат. и 10% от вас не стоили тех усилий, по увольнению, по найму человека из канады и как результат вас в послдедствии. это чисто мое мнение основанное на полученной иноформации (по моему это очевидно). игры с меньшим процентом отзывов и меньшими напрягами вполне нормально отбивают вложенния в них.
Дмитрий: Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps.... Ничего сверхнавороченного не было - игра 2d, вид сверху, помещения, толпы зомби, крафт и т.п.
всего пару сотен в 2д? игра сделанная не в конструкторе и световой движок вами переписан? за сутки. вероятно ничего сложного ни в самой игре ни в используемых алгоритмах нет. тогда фпсов мало.
честно скажите - вы хвалитесь или поясняете ситуацию? Дмитрий: недостаточных скиллов программеров использовались сомнительные решения
было же всего 3 программера.
Дмитрий: поиск цели для атаки при спавне большого количества зомби. Тут пришлось перейти на нативный код, а позже полностью начать переписывать всю систему. Сейчас как раз заканчиваю её.
есть куча алгоритмов по поискам пути (цель - те же вершины). зачем было переписывать полностью? готовые решения не подходят?
просто непонятно причина, по которой упомянули сумму и сроки
Причина, по которой упомянул сумму и сроки - отразить, что это может приводить к реальным проблемам, а не только в теории.
что не требовало объяснений
Вы писали:
слышать "выдавалось примерно 3 FPS" - несколько странно. это российская компания? во первых уже хотя бы потому, что 3 фпса будут заметны сразу.
Здесь у вас выражено непонимание, как такое может быть и именно поэтому я описал ситуацию более подробно.
выпустить значит сделать игру? просто на мой взгляд выпустить включает в себя понятия сделать, и издать.
Именно - и сделать и издать. Игра начата, прошла Steam Greenlight, сейчас в раннем доступе. Осталось доделать, затем продвижение. Что вас смущает?
по моему этот человек, не желающий терять доверие какого то там издателя, немного не своим делом занялся. 60-70% вполне неплохой результат. и 10% от вас не стоили тех усилий, по увольнению, по найму человека из канады и как результат вас в послдедствии.
Ещё раз повторюсь: первый программист не имел достаточных знаний и умений, чтобы закончить игру. Он не смог сделать того, что нужно было и именно поэтому отношения с ним были прекращены. Когда программист находится по объявлению, то как-то нет возможности тщательно проверить его скиллы - всегда остаётся пространство для обмана/недоговорок и т.п. (что, конечно же, обусловлено попытками сэкономить на оплате профессионального программиста, но не в этом суть). Напоминаю, что это - ранний доступ, там самые базовые вещи игровой механики. При работе над основной частью игры всё стало бы только хуже. Перед людьми, уже заплатившими за игру, есть обязательства, были даны обещания по срокам апдейтов, релизов и т.п. Соответственно, когда программер начинает затягивать работу (беря большие сроки на элементарные задачи) - это в первую очередь «бьёт» по заказчику и выбора особого нет, приходится искать нового исполнителя (например, на исправление производительности светового движка второй программер попросил две недели). Сначала работа делается достаточно быстро и никаких проблем не возникает, но когда проект разрастается и из-за неверных решений становится трудным в поддержке, то начинающие программисты моментально теряют энтузиазм. Именно это и произошло. Два раза.
Сам же заказчик уже выпустил не одну игру и почти все из них были весьма успешными. И в течении нескольких лет он зарабатывал именно этим, но в силу некоторых обстоятельств, пришлось сделать паузу, а сейчас он опять занялся играми.
Есть другой программист, с которым он делал предыдущие игры и в данный момент также с ним делает игру. Просто проект, о котором речь - дополнительный, так как есть время и ресурсы на него. Более того, неделю назад он начал третью игру, наняв ещё одного программиста. Так что, определённо, он занимается своим делом.
всего пару сотен в 2д? игра сделанная не в конструкторе и световой движок вами переписан? за сутки. вероятно ничего сложного ни в самой игре ни в используемых алгоритмах нет. тогда фпсов мало.
У меня написано:
Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps.
То есть этот фпс игра стала выдавать после исправления только одного светового движка. После некоторых других оптимизаций он перевалил за тысячу, а сейчас даже в пиковых нагрузках составляет несколько сотен.
честно скажите - вы хвалитесь или поясняете ситуацию?
Я уже давно не школьник, чтобы хвалиться. Вы выразили непонимание, как такая ситуация может возникнуть - я пояснил.
было же всего 3 программера
И что вас смущает в фразе «недостаточных скиллов программеров использовались сомнительные решения»? Подразумеваемое двух предыдущих поменяет смысл фразы?
есть куча алгоритмов по поискам пути (цель - те же вершины).
Безусловно. Я вроде и не говорил, что изобретаю свой собственный алгоритм.
У меня сейчас используется комбинированный поиск из A*, потенциальных полей и волнового алгоритма.
зачем было переписывать полностью? готовые решения не подходят?
Во-первых, существующее решение должно вписываться в существующую архитектуру игры. Во-вторых, решение должно быть оптимальным для игры (помещения/лабиринты/открытые пространства/этажи/разная проходимость и разные способы перемещения/разные размеры юнитов и т.д - всё это может значительно меняться от игры к игре). В-третьих, старый код (поведение и механика) глубоко завязан на старую систему, а потому нужно решение, позволяющее сделать всё с как можно меньшим количеством работы. Если бы я нашел готовое подходящее решение, то, конечно же, использовал бы его.
P.S. Не вижу смысла продолжать этот разговор, тем более - здесь, потому предлагаю на этом закончить. Мои вопросы в данном сообщении являются риторическими, а потому отвечать на них не обязательно.
Blender сделан не для того, чтобы на нем игры делали, так что его сразу отметайте.
Unity + C# проще в освоении, чем UE4/CryEngine + C++. И в целом, я думаю, игры на нем побыстрее будет писать. Цена этому - относительно низкая производительность. Так что если в вашей игре не планируется крутая графика, то можно остановиться на Unity. Если планируется, то выбирайте между последними двумя. Что из них лучше - не знаю, однако лично я отдал бы предпочтение UE4 как минимум за открытые исходники.
Насчет цен на движки - это легко гуглится, сами сможете найти, даже расписывать не буду.
