Создание игр c Qt

http://www.crossplatform.ru/ не?

Это к чему? Я понимаю что в теории можно, я спрашиваю про наличие подводных камней.

>Или есть подводные камни? Скорость? Функционал?

Напоминает «Есть ли у собаки блохи?» Как говорится, ответить могут только господь и ветеринар (и то, второму сначала надо осмотреть конкретную собаку). Без списка целевых платформ, номеров версий ОСей и фреймворка, архитектурных особенностей конкретной игры(!) и доступного железа, вопросы имеют мало смысла. В теории можно все, особенно без конкретики - в жизни граблей много. Она сложная. Обычно ограничиваются какой-то «разумной» (достаточной) степенью кросплатформенности.

Извиняюсь, ошибку понял, тогда попробую переформулировать вопрос:

Если начать писать игру с нуля(свой простой движок) и начать писать в Qt, то можно ли говорить с большой долей уверенности что она легко соберется и скомпилируется для Linux, Win, OSX, и там пойдёт нормально.
И будут ли у такого способа разработки минусы по сравнению с использованием кросплатворменных библиотек?

В правильном вопросе - половина ответа ;)

«Если начать писать игру с нуля» -> «она легко соберется и скомпилируется» не факт... Да и расслабляться рано. Если она сразу соберется - значит ты избежал тривиальных ошибок. Самое интересное будет, если она сразу запустится, и первое время будет вести себя хорошо (сказка!) Потому что для этого надо знать, какие грабли где лежат. (Авторы сторонних движков/фреймворков как минимум подумали за тебя кучу вопросов обеспечения переносимости (возможно, с костылями, но хоть как-то), а тебе придется до всего доходить самому и Qt тут не панацея: даже используя Qt, некоторые программисты умудряются делать о совершенно разных системах удивительные предположения. Пример из жизни... безобидный, но поучительный: одна американская контора писала пусть не игру, а P2P-систему. В декларациях, понятно, космические скорости передачи, поддержка Lin-Win-OSX... Нам скинули на аутсорц, чтоб мы из нее сделали фреймворк. В общем, там были допущения, такого плана: сравнение путей к шаре в папке типа /home/Desktop методом lowcase & compare работало в Win и OSX и внезапно сбоило в Linux. «Волшебная скорость» передачи достигалась за счет отключения механизма надежности TCP (в книжках не рекомендуют так делать, особенно если нет своего механизма). На OSX мы не сразу нашли, куда пишется лог... Прога его спокойненько вываливала внутрь пакета с экзеком. Пока размер файла не проверишь - не поймешь, в чем юмор... На максимальных уровнях дебага, конечно - с полными дампами того, что тестеры пытаются передать. Обнаружили, когда место на маке закончилось. То есть внезапно... И это прога из продакшна, с лицензиями и платной поддержкой. Это из наименее опасных подводных камней. Плюс готовых библиотек - не надо ходить по всем граблям... Но... Минусы готовых библиотек - если у них нет сорцов, как говорится, plug & pray, потому что неизвестно как именно обходили грабли... И какие из них не заметили. Если сорцы есть - можно иногда ловить себя на мысли, что хочется взять и у^W все переписать с нуля :)

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

если испльзовать только Qt, то проблем будет меньше, но зачем писать игру с opengl на Qt?

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

Так что, забудьте на время про другие платформы, закройте ваш Emacs\VIM\Eclipse\, откройте LibreOffice и начинайте писать на русском языке (не забывая сдабривать его иллюстрациями, блок-схемами и псевдокодом).

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

>вот скажите мне, какой мудак придумал, что написание игры - это программирование

А что же это? Опять ляпнул не подумав?

Это работа сотни дизайнеров\художников\моделлеров\сценаристов. По большому счёту у программера в этом процессе самая рутиная и обезьянья работа.

Проводя аналогию, программер в геймдеве - это оператор в кинематографе. Легко заменямеый винтик, делающий рутиную и чёрную работу.

> Проводя аналогию

Аналогия ложная.

>Вот решил я изучать OpenGL, и подумал: если писать в Qt то для портирования необходимо всего лишь собрать проект в другой ОС?

Если ты решил изучать OpenGL, то зачем тебе Qt?

>Если начать писать игру с нуля(свой простой движок) и начать писать в Qt, то можно ли говорить с большой долей уверенности что она легко соберется и скомпилируется для Linux, Win, OSX, и там пойдёт нормально.

Да. Но используя OpenGL, не завязываясь на Qt, кросс-платформенность будет лучше (iOS и Android, например)

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

> Да. Но используя OpenGL, не завязываясь на Qt, кросс-платформенность будет лучше (iOS и Android, например)

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

>>Если ты решил изучать OpenGL, то зачем тебе Qt?

А разве Qt не сможет заменить SDL?

>>только до тех пор пока не понадобятся потоки, сеть, упаковка данных, работа с разными форматами изображений и т.д.


Я про тоже и говорю.

>А разве Qt не сможет заменить SDL?

Разве SDL не сможет заменить Qt?

В чём профит SDL? Я никак не могу понять...

Ты опять путаешь программиста и кодирующую обезьяну.

в том, что эта штука, например, поддерживает игровые консоли

вообще ты можешь писать движок с применением QtCore, QtNetwork и др. компонентов не связанных с QtGui. Делать графику на QtGui я бы рекомендовал только «казуальные» игрушки (например, пасьянсы какие-нибудь:). На QtOpenGL особенно не рассчитывай - все равно придется использовать GL-ные функции напрямую

В QtOpenGL их нет, или работаю неправильно?

ну разве что некоторые фичи для работы с gl-буфером и шейдерами

То есть по-твоему в геймдеве есть кто-то помимо кодирующих обизян? ОХВААААУУУУ..... Для никогда не работавших в геймдеве:

Всё решают продюсер + геймдизайнер. Всё. Остальные - обезьяны, выполняющие описанное в диздоке. И если у художников и моделлеров есть хоть какая-то творческая составляющая в работе, то у кодеров её нет. Разве что на консолях, но там скорее творчество выражается в «как из говна и палки смастерить конфету». Программистами работают в других областях, в которых не расклеивают объявления о приёме на работу, а сами звонят и сами умоляют работать на них, а ты сообщаешь им свой прайс. Вот это и называется программист. Учи хаскель и матан, епта.

Ты еманулся? ГПЛьная библиотека поддерживается на анально - огороженных проприетарных устройствах с проприетарным софтом и анально - порабощёнными NDA разработчиками?

>Учи хаскель и матан, епта.

Ну матан-то понятно, а хацкель зойчем нужен?

Qt не нужно - лишняя жирная зависимость. Юзай SDL, оно тоже предоставляет кроссплатформенный доступ ко всяким goodies.

В QT таки сделали Input?

И да, зачем кутэ в приложениях, которые работают в полноэкранном (реже в оконном) режиме и которые не имеют всяких контролсов?

Современный, строго типизированный, компилируется в натив, в руке как влитой, быдло боится, да с такими то паттерн матчингом и монадами.

>То есть по-твоему в геймдеве есть кто-то помимо кодирующих обизян? ОХВААААУУУУ

Всё решают продюсер + геймдизайнер.

Вот, ты уже назвал двух, кроме программиста. Ты сам себе противоречишь.

>Современный, строго типизированный, компилируется в натив, в руке как влитой, быдло боится, да с такими то паттерн матчингом и монадами.

Фи. С наше все.

И что он годится на что-то сложнее чем считание факториалов? А то на ЛОРе только про это вопросы по хаскелю. Не похоже, чтобы на хаскеле писали что-то полезное. Love5an уже писал про это.

Ну и скажи это все разработчикам nethack и других инди-игр.

Подразумевалось: «среди части геймдеверского коллектива, которая непосредственно занята исполнительской работой».

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

А что с инди играми? Ну да их писал один человек, те инди-игры которые стали известными, начали продаваться и про которые не забыли прошли под прессом издателя (где разработчику говорили что и как нужно делать). А люди, подобные ZUN'у и Джонатану есть, да, но их очень мало.

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

> уж

обезьяньей

селффикс

>Без диздока - нет игры, начальный этап разработки игры - проработка игры на уровне диздока.

Не сомневаюсь, я столько мелких игр начинал делать, и все запорол из-за того, что хотелось сразу сесть и кодить, а не писать документацию.

1. SDL ни разу не GPL

2. Я имел в виду, что SDL поддерживает консоли, а не то, что она поддерживается производителями

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