gamedev

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

Перечислю основной софт, который мне приходилось использовать во время разработки игр. Эта информация может быть полезна при подготовке нового рабочего места разработчика игр. total commander (иногда far), желательно сразу с паком плагинов visual studio + visual assist ( также хорошо поставить цветовую схему  http://ethanschoonover.com/solarized , и шрифт оптимизированный для программирования ) lua for visual studio tortoise svn (иногда git), araxis merge, source tree notepad++ или scite photoshop ( обычно требуется ставить несколько версий CS 6 и младше) paint .net - для быстрого редактирования png, возможно другие легкие графические редакторы иногда что-то векторное inkscape, adobe illustrator пакет офисных програм: word, excel, иногда powerpoint players: foobar или другой с множеством проигрываемых форматов иногда: flash, 3dmax, blender, soundforge различные вьюеры текстовых, графических и прочих мультимедийных форматов: pdf, fb2, jpg, tga etc.  Это базовый набор,

Предыдущий мой пост был о компании X в целом. Теперь напишу к какому результату приводит такая организация на примере достаточно крупного проекта, в котором я один из двух программистов. Итак что мы имеем: Нет лида на протяжении всего проекта - одно это как пуля в лоб проекту Как следствие что нет лида, нет системы управления проектом, нет работающего процесса разработки. Постоянные попытки улучшить и изобрести велосипед, тогда как в индустрии уже давно всё известно и работает. Эти попытки, помимо того что ни к чему не приводят, ещё отнимают время и нервы. Джира, редмайн, трелло, гуглодоки, таблицы разбросанные по свн-ну и никем не контролируемые. Постоянные переходы от одной системы к другой - всё это следствие отсутствия лида с самого начала проекта.  Ядро, каркас, фундамент, архитектура (называйте как хотите) заложено студентом. Разработчики вынуждены его тянуть финала (кончины?) проекта. Переписывать не дают на протяжении всего проекта, обосновывая тем, что это не продано, эт

Хочу поделиться мыслями по поводу эффективности разработки игр. Об эффективности начинаешь задумываться когда работаешь в крайне неэффективной системе, возникает вопрос- "а как надо сделать чтобы такого не было?". Всё будет рассказано на примере компании, где я работал рядовым наемным программистом и выполнял задачи лида. Это сравнительно маленькая компания, всегда меньше 10 программистов( эти 10 человек всегда разные, из-за большой текучки) и порядка 15 художников. В этой компании допущены все возможные ошибки управления, о которых только можно представить, поэтому хорошо расссматривать её как кононический пример. Все мои наблюдения  касаются исключительно геймдевелоперских компаний и я не стремлюсь обобщать и экстраполировать опыт и выводы на другие типы компаний. Итак, приступим. Мысль 1 О модных методологиях разработки Существуют различные методы ведения разработки такие как agile, lean, kanban, scrum, gamification, hive mind. Это не только методы разработки, но

Как не крути игра пишется под определенные платформы. Каждая платформа предоставляет определенные преимущества и обладает некоторыми недостатками и ограничениями. При написании кроссплатформенной игры мы не пользуемся удобствами платформ ( т.к. они есть только на конкретной платформе), но должны учитывать ограничения каждой платформы в своей игре ( т.к. код игры один на все платформы) . Поэтому при написании движка все платформозависимые вещи локализуются в одном месте и к ним пишется общий интерфейс, с которым игра уже непосредственно взаимодействует. Портирование или перенос игры с одной платформы на другую - процесс не творческий.  Особенно если при написании оригинальной игры не думали о переносимости. Задача  сводится к выделению и переписыванию платформенных компонент. Такими компонентами являются - рендеринг, ввод/вывод, звук. Обычно сначала просто добиваются компиляции на целевой платформе. Все участки кода, которые не компилируются просто комментируются, например, с помет