Здравствуйте. Я Михаил Капелько, программист команды Opensource Game Studio. Я хочу рассказать вам, что мы узнали при приближении к выпуску OGS Mahjong 1.0, нашему последнему релизу пасьянса Маджонг (но не последнему в серии Маджонг). Эта статья продолжает предыдущую: Долгий путь к Mahjong 0.7
Год назад в мае 2011-го мы выпустили OGS Mahjong 0.7, он дался нам с большим трудом. В этом году в сентябре 2012-го мы выпустили OGS Mahjong 1.0. Во время разработки 1.0 мы хотели распрастранить нашу игру на всех дистрибутивах Linux, а также Mac OS X. К сожалению, нам это не удалось, т.к. OGS Mahjong использует OGRE и OIS.
OGRE
Я начал использовать нестабильную (на тот момент) ветку OGRE 1.8 летом 2010-го для OGS Mahjong, когда реализовывал пересоздание окна игры без перезагрузки ресурсов. Мои изменения для осуществления этого были приняты в ветку 1.8 тем же летом.
Я думал тогда, что стабильный релиз OGRE 1.8 будет не более, чем через год, чтобы к этому времени OGS Mahjong 1.0 мог уже зависеть от стабильной версии OGRE. OGRE 1.8 был выпущен 28 мая 2012-го.
Но к этому времени:
1) мы попробовали OIS 1.3 (последний на тот момент), он нам не подошёл (детали ниже).
2) я внёс изменения в ещё один файл OGRE (для истории: Overlay::setMaterialName), но не передал его разработчикам OGRE, т.к. уже знал, что это маленькое изменение попадёт в релиз в лучшем случае через год.
FreeImage
OGRE использует FreeImage в качестве главного кодека изображений. Основная проблема FreeImage в том, что библиотека не поддерживается дистрибутивом Gentoo ввиду того, что разработчики сопротивляются использованию системных библиотек zlib, png и т.д… Вместо этого, они статически включают все эти библиотеки в FreeImage.
Они исправили проблему видимости символов путём использования специального флага, что всё равно оказалось тщетно.
Поэтому мы поступаем именно так, как предложил автор в 3-м варианте, — выбрасываем FreeImage. В довесок ещё несколько библиотек.
OIS
OIS — это ещё одна редко обновляемая библиотека. Недавно вышел релиз 1.3, который полностью испортил обработку нажатия клавиш для нас. Логика повторения нажатия клавиши была изменена, из-за чего OGS Mahjong просто перестал принимать нажатия клавиш через 30 секунд после запуска.
Я сообщал разработчику о данной проблеме, но он не смог её воспроизвести. Мы вынуждены были остаться на версии 1.2 для Linux.
OIS 1.3 не собирается под MinGW, лишь последняя (на тот момент) версия SVN.
Что касается Mac OS X, OIS подвела нас и тут, потому что человек, пытавшийся помочь нам со сборкой Маджонга под Mac OS X, просто не смог собрать OIS из-за ошибок компиляции.
Т.к. версия 1.3 была выпущена, она поставляется сейчас со всеми дистрибутивами Linux, что накрывает медным тазом наше желание включить OGS Mahjong во все дистрибутивы Linux. Неприемлимо.
CEGUI
Совершенно иначе обстояли дела с библиотекой CEGUI: отличная поддержка от команды, особенно CrazyEddie, который очень сильно помог с разработкой OGS Mahjong. Но у CEGUI есть очень большой минус: нет удобных средств для дизайнеров. Всю разработку GUI делал я один, а GUI во время разработки очень часто меняется. В итоге, разработка GUI заняла больше времени, чем следовало.
Как видите, вышеназванные библиотеки довольно сильно нас ограничили. Больше, чем я, единственный программист, могу выдержать. Я понял: если мы хотим делать игры, а не постоянно исправлять ошибки, допущенные другими разработчиками, нам необходимо отказаться от этих библиотек. Конечно, мы можем потратить всю нашу жизнь на исправление чужих ошибок, но, к счастью, существуют более лучшие альтернативы (с точки зрения зависимостей и возможностей).
OpenSceneGraph
Я открыл для себя OpenSceneGraph благодаря двум недавно вышедшим книгам:
1) OpenSceneGraph Beginners Guide, 2010.
2) OpenSceneGraph Cookboox, 2012.
Первый раз я встречал OpenSceneGraph тогда, когда сменил Lightfeather на OGRE в 2010-м. OSG, будучи сложной библиотекой, не привлекла меня тогда, потому что я просто не смог понять её самоучители. К счастью, в этот раз на помощь пришли вышеназванные книги, которые показали отличную структуру OSG, поддержку распрастранённых техник прямо из коробки, отсутствие зависимости от FreeImage. Также OSG присутствует в дистрибутивах Linux.
Поддержка распрастранённых техник прямо из коробки — это ещё одна серьёзная проблема, которая была с OGRE. Утверждается, что OGRE поддерживает текстурные тени (shadow mapping), да, но лишь с помощью Cg. Ещё одна зависимость! Самоучителя по текстурным теням на GLSL для OGRE просто не было. Я почти не разбираюсь в шейдерах, мне не удалось реализовать текстурные тени в течение месяца, поэтому мы вынуждены были использовать стенсильные (stencil) в OGS Mahjong 1.0.
Одна из книг OSG содержала пример с мягкими тенями (soft shadow mapping). OSG поддерживает из коробки несколько техник отрисовки теней. Нет нужды даже писать шейдер. Он уже написан за тебя! Чтобы поменять стенсильные тени на мягкие, нужно изменить всего лишь одну строку кода.
Я спрашивал о реализации теней в GLSL на форумах OGRE, но без результата. Поэтому когда в следующий раз увидите количество сообщений на форумах OGRE, не думайте, что на все вопросы там дают ответы. Для сложных вещей всё совсем наоборот.
Другое огромное преимущество OSG в том, что главный разработчик Robert всё ещё активно участвует в разработке OSG и часто отвечает на вопросы в mailing lists (OSG уже 12 лет!). OGRE очень сильно захирел после ухода Sinbad.
Присутствие OSG в дистрибутивах Linux объясняется в том числе и отсутствием зависимости от хрени вроде FreeImage. OSG использует libpng для работы с PNG, например. В конце концов, вы не будете использовать 100500 разных форматов, один или два от силы.
libRocket
Единственная альтернатива CEGUI. На данный момент я прошёл несколько самоучителей, они оказались не столь хорошими и красивыми, как это может показаться после первого взгляда на libRocket, но эта библиотека использует подмножество HTML/CSS для описания интерфейса (да, поддержка HTML/CSS — это ложь). Этот факт должен освободить меня от необходимости делать GUI. Если это удастся, мы продолжим использовать libRocket. Иначе мы вернёмся обратно к CEGUI, где к тому моменту, надеюсь, будет реализован CEED для дизайнеров (Kulik, продолжай начатое!).
Python
Одним из первых требований для MJIN2 (нашего нового игрового движка) было поддержка Python для GUI и логики. Позже я вдруг подумал, почему не сделать MJIN2 бибилиотекой на C++, а игру полностью на Python, не только логику и GUI? Тут на помощь приходит SWIG, который может сгенерировать обёртку Python для библиотеки на C++.
С использованием Python мы надеемся увеличить темпы разработки. Я проанализировал историю коммитов игры и движка. Оказалось, коммитов в игре было сделано в 2 раза больше, чем в движке. Поэтому написание игры на Python должно повысить скорость разработки благодаря меньшему количеству кода, более быстрой разработке.
Т.к. мы собираемся поддержать Android и iOS, мы не будем использовать Python на этих платформах из-за ограничений производительности, но мы сможем написать финальные версии игр на C++ или Java, т.к. MJIN2 + SWIG позволит писать игру практически на любом языке (C++ нативно и более 20 языков с помощью SWIG).
Мы очень многое меняем в подходе к разработке игр. Посмотрим, во что это выльется.
Автор: kornerr
