Авторизация  

   

Подпишитесь на нас  

   

Поиск по сайту  

   

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

Что нужно для разработки

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

К первой группе относятся языки программирования, а также используемые библиотеки и фреймворки. Сюда же я отнесу и IDE (Integrated Development Environmentинтегрированная среда разработки). Хотя в принципе писать программы можно используя только простейший текстовый редактор и компилятор+компоновщик, все же я считаю, что мощная среда разработки предоставляет такие значительные удобства и настолько повышает эффективность работы, что она вправе относиться к жизненно необходимым инструментам разработки.

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

Не буду здесь подробно описывать все прелести рефакторинга и его идеологию, опишу лишь формально, без всяких пояснений, основную его методологию (опираясь на замечательную книжку Мартина Фаулера «Рефакторинг. Улучшение существующего кода»): находим участок кода, подлежащий улучшению; производим малое изменение кода, являющееся частью проводимого рефакторинга; производим компиляцию и автоматическое тестирование, чтобы убедиться, что код не «сломался»; если все в порядке – повторяем предыдущие два шага, если нет – полностью отменяем последнее малое (!) изменение и пробуем еще раз.

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

Для решения первой задачи обычно используются средства для проведения модульного тестирования (unit testing); для решения второй – системы контроля версий (VСS, Version Control System).

Автоматическое тестирование помогает убедиться в корректности работы программы на протяжение всего процесса работы, своевременно обнаруживать ошибки и тем значительно снижать время на отладку, а зачастую – позволяет полностью переложить проверку корректности того или иного алгоритма с разработчика на систему тестирования. Не всегда очевидно, правильно ли составлен алгоритм, или же надо в нем что-то поменять. Быстрый прогон тестов помогает не мучиться сомнениями, а сразу увидеть все своими глазами и быстро внести необходимые поправки.

Системы же контроля версий помогают, как было сказано выше, быстро откатить последние внесенные изменения, если в них был обнаружен изъян (зачастую начать заново проще, чем пытаться отлаживать некорректный код). Кроме того, они позволяют взглянуть на старый код и понять, почему он вообще работал, и каков смысл того или иного его участка (путем сравнения с тем, что было раньше). Если же речь идет о командной разработке, то к плюсам добавляется синхронизация общей работы, поиск виноватого в поломке программы и уяснение смысла кода, написанного другими (опять же, путем сравнения с прошлыми версиями).

Также ко второй группе инструментов можно отнести системы профилирования (профайлеры, profiler), которые позволяют выявить узкие места в программе. Если, скажем, приложение медленно работает, то далеко не всегда можно точно угадать, какой именно участок кода сильнее всего грузит процессор.

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

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

Язык программирования – C++, стандарт C++ 11

Почему именно «плюсы»? Главным образом потому, что это язык, с которым я лучше всего знаком; кроме того, это эффективный язык общего назначения, предоставляющий богатые возможности; он очень популярен, а значит – для него создано множество полезных библиотек и фреймворков.

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

Библиотека Qt, версия 5.2

Для создания приложений с GUI с использованием чистого (native) C++ кьют – едва ли не единственный хороший вариант. Возможные альтернативы – библиотеки, используемые в средах разработки C++ Builder (VCL) и MS Visual Studio (MFC и Windows Forms) я не считаю достаточно привлекательными.

MFC – устаревшая и довольно уродливая библиотека, написанная в псевдо-ООП стиле (сам объектно-ориентированный подход тогда еще только проходил свое становление, best practices еще не были выработаны); Windows Forms предназначена для платформы .NET, а значит, исключает использование чистого C++ (еще одного уродца – C++ CLI, очень плохой гибрид двух хороших языков C++ и C# – лучше никогда не использовать).

У меня есть в целом положительный опыт работы с C++ Builder (правда, с очень старой версией - шестой), но все же библиотека VCL создана прежде всего под Delphi; кроме того, у меня есть какая-то абстрактная убежденность (не основанная на личном опыте работы с современными версиями билдера), что Qt все-таки по всем или почти всем статьям лучше и перспективнее его.

Во всяком случае, кьют – очень мощная, кроссплатформенная и динамично развивающаяся библиотека, работать с которой мне нравится. Более того, ее лицензия позволяет бесплатное использование в коммерческих проектах (при условии не внесения в саму библиотеку никаких изменений).

Что касается версии, то 5.2 привлекательна прежде всего тем, что в ней обещана полная поддержка мобильных платформ (в частности, Android).

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

Правда, Qt 5.2 все еще не вышла, но, во-первых, релиз ожидается уже очень скоро (предварительно – 11 декабря, release candidate был выпущен 29 ноября), во-вторых, пятая версия обладает обратной совместимостью с четвертой, поэтому я могу начать работать в привычной мне 4.6, а потом без особых проблем перейти на 5.2 и начать использовать ее новые возможности.

Среда разработки – Qt Creator

Коль скоро я использую кьют, то лучше всего работать в IDE, специально созданной именно под эту библиотеку. Мне также нравится MS Visual Studio, которую к тому же можно подружить с Qt, но, во-первых, это требует довольно сложных телодвижений; во-вторых, Qt Creator все-таки лучше заточен под библиотеку, являясь при этом довольно мощной средой разработки; в-третьих, лицензия студии требует покупки для использования в коммерческих целях.

Еще один важный момент связан с предоставлением справки. С одной стороны, Qt Assistant предоставляет отличный хелп по всем возможностям Qt. С другой – отсутствует справка по самому языку C++, что зачастую приводит к неудобствам. Впрочем, сетевые ресурсы (например, MSDN) отчасти сглаживают эту проблему.

Что касается версии Qt Creator, то, несомненно, стоит использовать ту, которая поддерживает нужную версию кьюта. Как правило, самая свежая IDE является наилучшим вариантом.

Скриптовый язык – Lua

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

К версии Lua, аналогично Qt Creator, особых требований нет – просто чем новее, тем лучше. Тем более, что значительных изменений не было довольно давно – нынешняя, пятая, крупная версия появилась шесть лет назад.

Система контроля версий – Mercurial

Главный критерий, по которому я выбрал именно Mercurial (она же Hg) – это наличие графических оболочек и простота освоения в сравнении с другими достойными VCS. Поскольку я пока не сталкивался с подобными инструментами, этот параметр важнее, чем, скажем, большая мощь Git.

Система unit-тестирования – Google Testing Framework

Изначально я собирался первое время обходиться QtTestLib (главное ее преимущество – она доступна «из коробки» при работе с Qt), а затем присмотреть более перспективный вариант.

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

Впрочем, QtTestLib имеет по крайней мере одно преимущество – она позволяет проводить тестирование GUI, созданного в Qt. Так что окончательно сбрасывать ее со счетов ни в коем случае не стоит; по крайней мере, при работе над игровым редактором эта библиотека может очень пригодиться.

Профайлер – пока не определился

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

Итак, в общих чертах с выбором инструментов я определился (если к моменту начала работы над кодом релиз Qt 5.2 еще не состоится, то работать я начну с версией 4.6, а затем перейду на 5.2). Теперь можно начать проектирование архитектуры игры, попутно занимаясь изучением Mercurial и Google Test.

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

   
© Создание игры - взгляд изнутри. The Gamedev. При использовании материалов сайта ссылка на источник обязательна.