как Вы дошли до Unity? (4 стр)

Бунтарчик
> Так что очевидно что крупным конторам выгоднее писать своё.

зачем если оно все стало фактически даром

zlos
> Не проще ли просто эти расходы не иметь?
Это окупается скоростью разработки контента для специфических игровых аспектов. Скажем так, на своем движке проще делать тулзы, заточенные под проект.

zlos
> Время и ресурсы этих опытных программистов можно потратить на реализацию лучшего геймплея
Геймлей делают дизайнеры. Если программер нужен для чего-то, кроме написания систем игрового движка, то такой пайплайн разработки неудобный и медленный.

Ataman
Что потом делать с этим движком, когда программист сменится?)
И потом еще каждого дизайнера обучать работе с движком и его самодельными тулзами.

Хотя есть и крутые примеры типа Ubisoft и UbiArt Framework- http://www.youtube.com/watch?v=y-chi097uV4 И такие штуки впечатляют.
Но с другой стороны один из программистов который делал этот фреймворк ушел от них и точно так же в Unity надобавлял всех тулз чего ему понадобились
https://www.youtube.com/watch?v=bUGbXThraVM

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

crol
> Что потом делать с этим движком, когда программист сменится?)
А чем игровой движек в этом плане отличается от других програмных продуктов?

Ataman
Если самописный движок узко специализирован, уход программиста ставит крест на расширении функционала, соответственно.

KaZuaL
> Если самописный движок узко специализирован, уход программиста ставит крест на
> расширении функционала, соответственно.
Новый программер продолжит то, на чем остановился старый. В чем проблема? Мы же не о проЭктах на энтузиазме говорим, да?
И что значит специализирован? Специализированы тулзы и расширения игрового движка, а низкоуровневой части (рендеру, физике, ядру скриптинга) не обязательно меняться от проекта к проекту.

Более естественно и уверенно писать с использованием своей графической библиотеки, облегчающей работу с низкоуровневым API. Очень полезно на 100% контролировать логику работы программы: вручную загрузил модель, сделал установки, отрендерил, и т.д., нежели иметь дело с неким движком, который все равно полностью изучить невозможно.

Лично меня вполне устроил бы уровень графики на уровне DirectX 6 (полигоны, текстуры, прозрачность - по цветовому ключу, как в 2D, освещение и элементарная физика). На таком уровне я вполне написал бы собственный движок. Но подобную игру не возьмет серьезный издатель. Нынешняя 3D-графика высокотехнологична и эта планка постоянно поднимается. Отдельному инди-программисту или небольшой компании соответствовать этим требованиям очень сложно.

Достоинство Unity - это его коммерческий характер, что является некоторой гарантией прилежной работы разработчиков. Альтернативные бесплатные программные продукты (которые сейчас пишутся также на манер Unity, обязательно с редактором игрового мира) еще менее застрахованы от багов, тормозов и ошибок в архитектуре.

Ataman
> Новый программер продолжит то, на чем остановился старый. В чем проблема?
> Мы же не о проЭктах на энтузиазме говорим, да?
Если так, то имеет смысл упомянуть, что день работы над движком (включая изучение кода одного программиста другим) стоит, в среднем $180-240.
Соответственно, каждая такая итерация будет повышать стоимость, да и написание самого движка имеет смысл только если аналоги дороже затрат на разработку.

> И что значит специализирован?
Студия работала с 2д-ХОГами для ретейла, а надо физический 3Д-ранер, привязанный к онлайну и транзакциям- типичный пример по нынешним временам.)

zlos
> Время и ресурсы этих опытных программистов можно потратить на реализацию
> лучшего геймплея - толку от этого будет больше. Игрокам же плевать на какой
> технологии игра сделана.
неа, не плевать. я вот знаю что если юнити - то значит придется бороться с забагованным тормозящим чудом. Еще не было ни одного исключения... вот взять хиртстон. Вот у близард старкрафты, вовы, дьяблы - на общем фоне других игр наиболее стабильные игры. И вот heartstone - у меня 100% первый заход - зависание и вылет. Обрывы связи и вылет. зависания при поиске противника и вылет. Одни вылеты. Юнити же. И это продукт от команды у которой есть деньги на качество. и это совсем примитивный по техническому уровню продукт.

zlos
> Время и ресурсы этих опытных программистов можно потратить на реализацию
> лучшего геймплея - толку от этого будет больше. Игрокам же плевать на какой
> технологии игра сделана.
ну-ну. на геймплей потратить... В конструкторе "сделай все сам". Несерьезно. эти программисты дальше будут писать всякие камеры и самописные батчи мешей с тенями и сандшафтами... только среди чужих костылей и уродской архитектуры на языке не предназначенном для этого.
Ну или обмазываться платными ассетами покупка которых как раз будет равна стоимости написания своего движка (ведь не факт что купленный ассет подойдет - уже многие пишут как накупили ассетов а потом поняли что легче их написать самим с нуля)

sinoby
> зачем если оно все стало фактически даром
нет.
смотри, если ты делаешь хоги, движок пишется за пару дней.
если ты пишешь что-то серьезное - то юнити слишком голый для этого, а значит тебе придется дальше писать движковую часть... например управление камерой. Только писать такие вещи на юнити не самое приятное - нужно запасаться успокоительным
Вывод - ты потратишь теже самые деньги

Потому что по сути юнити - это голый рендер, примитивное управление сценой и мало кому нужный редактор. (кстати, две из этих вещей у меня в своем движке уже есть)

crol
> Что потом делать с этим движком, когда программист сменится?)
А что случится когда из проекта уйдет писатель ассетов и скриптов для юнити?
ведь ровно теже проблемы. даже хуже. Я еще не видел ни одного скрипта на юнити который бы легко было читать и изменять. даже среди платных. Что уж тогда говорить о труде студента подрабатывающего юнити программистом

Будет таже ситуация - пришел новый человек и сделал вывод что легче все переписать с нуля чем продолжить.

KaZuaL
> Если так, то имеет смысл упомянуть, что день работы над движком (включая
> изучение кода одного программиста другим) стоит, в среднем $180-240.
Допустим... Но это цена уровня крайзиса.

А сколько будет потрачено денег на покупку ассетов, их изучение, и последующее изменение под проект? Почему вы это не учитываете?

sinoby
> А еще интересует вопрос как вы дошли до юнити в хорошем смысле этого выражения,
> на чем писали, кодили и лепили до него?

Если отбросить всё, что было в прошлом веке, то в начале 2000-х хотел написать трёхмерную игрушку. С++ я тогда ещё знал (сейчас уже забыл), но интернета у меня не было и вообще ничего не было, кроме DX8 SDK и какой-то базовой книжки по OpenGL. Что-то там даже получилось: пальмочки торчали, человечек бегал, но всё это зверски тормозило, потому что я ещё не знал, что много DrawCalls ― это плохо, а узнать было негде. В результате я на это забил и потом писал всякое разное на C#, который знаю и люблю с версии 1.0.

Потом как-то захотел снова заняться игрушкой, полез искать движки. Нашёл UDK, NeoAxis, ещё парочку каких-то и недели две изучал их демо-проекты, читал документацию, смотрел, что движки из себя представляют и с какой стороны к ним подступиться. Потом вдруг наткнулся на Unity и оказалось, что к нему подступаться вообще не надо. Пара минут и Hello World трёхмерной графики готов ― твой кубик крутится на экране.

А после того как выяснилось, что изображения и модели можно просто как есть класть в проект и они готовы к использованию; что редактор хоть и выглядит аскетично, но в нём есть всё что надо, плюс расширяется до бесконечности; что писать можно в Visual Studio с Решарпером; что программно и на лету можно сгенерировать практически всё ― после этого остальные движки сразу пошли в корзину без сожалений.

Пользуюсь Unity с версии 3.0. Мне доступных возможностей хватает с головой. До сих пор остаются области, до которых посмотреть ещё руки не дошли. Иногда бывает, что сидишь и бьёшься головой в закрытую дверь, но потом оказывается, что или дверь открывается в другую сторону, или что рядом есть ещё две открытых.

> И жалеете ли сейчас что тратите на него время понимая что юнити это путь в
> никуда и самое труЪ это свой движочек?

Каждый дрочит, как он хочет, ― это всё, что я имею сказать по этому поводу.

war_zes
> У меня например был баг - когда при экспорте текстуры при попытке что-то ей
> изменить (фильтрацию там или еще чего) текстура портилась и юнити падал (на
> пустом проекте проверял много раз). Я три раза слал репорты... Один раз мне
> даже ответили - что не смогли воспроизвести ошибку. Ошибка была до 4.3.4, а
> также в бетах 5.0. И сейчас наверное есть.. Одна из многих причин почему я
> дропнул юнити.

Эту ошибку никто не смог воспроизвести. Мы тут на форуме тоже не смогли. За себя могу сказать, что я даже старался, но всё равно не смог. Невозможно исправить ошибку, которую нельзя воспроизвести.

> Еще я считаю уродством систему координат в 2D. Когда позиция задается в юнитах,
> а не пикселях, и в эти пиксели надо еще мудрено переводить

Очень мудрёная школьная арифметика, да.

---
(http://www.gamedev.ru/code/forum/?id=174189&page=35#m514)
> Да и я бы с радостью тоже на юнити заделал пару игр... Но почему только у меня
> возникают такие проблемы о которых другие даже не задумываются

У тебя просто талант такой присутствует.

alexzzzz
> Очень мудрёная школьная арифметика, да.
да, потому что ее надо написать и в других движках нет такой хрени

А кроме того ломается редактор (о котором тут много пишут) - как ты редактор научишь выводишь в пикселях?
То есть ты предлагаешь рисовать карту в C#? Ну и на кой черт тогда нужен юнити?

Я понимаю что школьникам не нужен контроль над позициями в пикселях - им банально будет лень поэтому сделали чтобы они тяп-ляп мышкой покидали на глаз (и пофиг что потом все сломается на разных экранах)... А мне вот он нужен - в том числе и в редакторе расставлять элементы в пиксельных позициях..  и уж контроль за размерами экрана лучше я сам буду делать - мне точно не нужно чтобы мой спрайт 16х16 пикселей на мобильниках превращался в 1х1 точку (а именно так и будет с юнитами)