Кроссплатформенная независимая разработка

Несколько лет назад, если вы написали на C и в некотором подмножестве C ++ и использовали достаточное количество абстракций платформы (через SDL или что-то еще), вы могли работать на любой платформе, на которую мог бы попасть инди - Linux, Windows, Mac OS различных версий. такие непонятные вещи, как BeOS, и открытые консоли, такие как GP2X и Dreamcast после смерти. Если в какой-то момент вы получили контракт на закрытую платформу, вы можете перенести свою игру на эту платформу с минимальными изменениями кода.

Сегодня независимые разработчики должны использовать XNA, чтобы получить Xbox 360 (и грядущий Windows Phone); не должен использовать XNA для работы где-либо еще, кроме Windows; до недавнего времени приходилось использовать Java на Android; Flash не работает на телефонах, HTML5 не работает на IE. В отличие, например, от DirectX против OpenGL или от Windows против Unix, это изменения основного языка, на котором вы пишете свой код, и его нельзя скопировать без написания компилятора. Вы можете переместить некоторую игровую логику в сценарии и включить интерпретатор - кроме случаев, когда вы не можете этого сделать, потому что iPhone SDK не позволяет этого, и производительность снижается, потому что никто не допускает JIT.

Итак, что вы можете сделать, если вы хотите по-настоящему кроссплатформенную портативную игру или даже просто значительный объем движка и логического кода?

Разве это не проблема, потому что платформы существенно разошлись - просто не стоит пытаться нацеливать на iPhone и Xbox 360 какой-либо общий код, потому что такая игра будет плохой? (Я нахожу это очень маловероятным. Я легко вижу желание поделиться игрой между телефоном с Windows Mobile и Android, или Xbox 360 и iPad.) Являются ли интерфейсы настолько высокоуровневыми, что время портирования ничтожно мало? (Я мог бы верить этому для бизнес-приложений, но не для игр со строгими требованиями к производительности.)

Это станет более выраженным в будущем? Будет ли разделение, несколько пугающее, все еще на линии продавцов? Будем ли мы все полагаться на высокоуровневое промежуточное ПО, такое как Flash или Unity, чтобы сделать что-нибудь кроссплатформенное?

tl; dr - портирует ли это проблему, станет ли она большей проблемой в будущем, и если да, то как мы ее решим?

Движок Unity поможет вам в этом. Напишите один раз, и вы получите Mac / Windows Standalone и веб-плеер. Настройте свои входы, помните о своих вызовах и вы на iOS / Android.

Для небольшого инди-разработчика, с ограниченными средствами / временем (и, возможно, больше внимания уделяется «делать что-то крутое», чем «делать что-то прибыльное»), попытка начать кросс-платформенную с самого начала может быть контрпродуктивной. Требуется много усилий для разработки надежных кроссплатформенных инструментов и технологий (различные графические API, порядковые номера, устройства ввода и т. Д.) - время, которое можно потратить на более творческую сторону разработки игр.

Но вы, вероятно, хотите убедиться, что у вас есть отличная игра, которая действительно хорошо работает на одной платформе, прежде чем беспокоиться о том, чтобы получить ее на как можно большем количестве платформ! Если игра провальная, нет смысла тратить время и силы на мультиплатформенный флоп, не так ли?

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

Если сторонние кроссплатформенные технологии / инструменты (например, Unity) являются опцией для вашего проекта, то это, безусловно, стоит рассмотреть.

Основными «проблемными платформами» для инди, по-видимому, являются Индийские игры Xbox360 (только C #, ограниченный доступ к сети и т. Д.) И, возможно, Android (огромные различия в производительности устройства / размере экрана / устройствах ввода). Если вы полны решимости поддержать их, ожидайте более значительную работу по переносу или планируйте сосредоточиться исключительно на них.

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

Независимо от того, нет или нет, самым большим препятствием на самом деле является дизайн. Как вы говорите, игра, которая работает на Xbox360 и iPad, может работать, но они также должны принципиально отличаться в плане дизайна. У 360 есть контроллер, у iPad сенсорный экран. Кроме того, разработка для 360 выполняется в Windows с использованием C # в качестве языка, iPad может быть ориентирован только на компьютеры Mac OS и с использованием C, C ++ или Objective-C. Или Javascript, если вы предпочитаете. Некоторые вещи просто не очень хорошо сочетаются с тем, что вы делаете.

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

Портирование имеет те же проблемы, что и когда-либо, но есть больше устройств для портирования. А некоторые порты просто не имеют смысла, если не перепроектировать ядро ​​игры. Это не проблема, которую можно решить, ее нужно рассмотреть с самого начала еще до того, как вы напишете свою первую строку кода. Тогда это будет управляемым, не больше, не меньше.

Я думаю, что необходим простой, переносимый и открытый интерфейс. Некоторые размышления:

В настоящее время существует четыре распространенных способа ввода в игру: клавиатуры, мыши, контроллеры и поверхности Multi-Touch. (Я пока остановлюсь на проблемах, связанных с различными возможностями, например, геймпадов и джойстиков, хотя в конечном итоге это следует решить.)

В идеале наш разработчик мог бы указать в общих чертах несколько различных пользовательских интерфейсов, которые имеют смысл для типа написанной игры. (Они могут решить предоставить пользовательский интерфейс клавиатуры и мыши, пользовательский интерфейс только для мыши и интерфейс Multi-Touch в качестве произвольного примера.)

Затем фреймворк отвечает за посредничество ввода-вывода между платформой и игровым кодом, подобно тому, как функционируют кроссплатформенные фреймворки с графическим интерфейсом, такие как QT и GTK.

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

Хорошо, теперь, когда я написал все это: кто-нибудь знает, существует ли уже такая структура?

С такими проектами, как MonoTouch и XNATouch, казалось, что XNA может помочь вам на большинстве платформ с небольшой настройкой. К сожалению, Apple как-то торпедировала это, когда они изменили свои Условия и положения, чтобы ограничить использование языков. Unity теперь работает практически во всем, хотя на XBOX вы получите XBLA, но не XBLIG, так что это не вариант для небольших инди.

Один из подходов может заключаться в создании инфраструктуры, которая использует одни и те же соглашения для нескольких языков / платформ, тогда это просто вопрос настройки синтаксиса для портирования игр. Возможно, вы захотите запустить свою игру во Flash, которая может быть разработана быстро и охватить большую аудиторию, затем, если это успешный порт для iPhone, XNA и т. Д. Таким образом, вы знаете, что у вас есть забавная игра, прежде чем чрезмерно совершать свои действия.

Я думаю, что это экономическая проблема, а не техническая проблема. У таких платформ, как xbox360, есть серьезный стимул к исключению, потому что они пытаются заставить пользователей выбирать свою платформу вместо какой-либо другой платформы. «У нас есть эти крутые эксклюзивные игры» гораздо интереснее, чем «мы также можем играть в такие игры, которые есть у всех». В экосистеме доминируют производители оборудования.

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

Я только что открыл Haxe и NME . Он претендует на роль кроссплатформенного приложения, которое поддерживает все основные настольные и мобильные устройства, а также Flash, из одной базы кода. Стоит посмотреть.

Кроссплатформенный инструмент разработки, который настолько нов, что я не обязательно рекомендую его, это http://www.monkeycoder.co.nz/

Это поражает каждую платформу, которую вы упомянули.

Хотя он слишком новый, чтобы по-настоящему судить, у него отличная родословная: его создатель ранее создал Blitz3D и BlitzMax, которые были отличными инструментами разработки для разработчиков инди-игр.

Мне повезло с SDK для трансляции - по крайней мере, на x86, и, очевидно, он хорошо нацелен на iPhone (хотя мне еще предстоит разместить приложение на iPhone).