Блог о разработке компьютерных игр
Очень удобно иметь под рукой скрипты для выполнения повседневных действий. А когда проект нужно часто собирать для просмотра или тестирования, то написание таких скриптов является необходимостью.
Ниже я привел скрипты, которые я использовал для автоматизации сборок с помощью TeamCity (но ничего не мешает запускать их например с Jenkins).
Эти же скрипты используются для повседневной работы и протестированы на различных версиях UE4, в них учтены некоторые существующие проблемы работы с UE.
Большое количество метаданных, хранящихся в git, и встроенные способы получения отчетов по ним дает некоторые инструменты для поиска источников тех или иных багов в коде. [Читать далее…]
Git-flow — наиболее популярная методология разработки проектов с использованием git.
Зачем нам вообще нужны какие-то методологии для работы с git?
Дело в том, что сам git не привязывает нас к какому-либо определённому способу разработки, и каждый разработчик, в теории, может работать с контролем версий так, как он хочет. Чтобы в таких условиях не погрузить наш репозиторий в хаос, нам нужно придумать и донести до всех разработчиков некий единый стандарт для работы с контролем версий в проекте.
Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.
В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.
И так, что же нам стоит знать о git-flow? [Читать далее…]
Пример ситуации: Вы делаете коммит текущего (не совсем стабильного) состояния рабочей копии, чтобы быстро поработать над какими-то другими задачами. Затем, вернувшись к работе над неоконченной задачей и завершив её вы делаете коммит и … понимаете что забыли проставить “amend”.
История коммитов получается примерно следующая.
ae02b31 Хорошие правки [develop]
d8428ca НЕ ПУШИТЬ! Неоконченные хорошие правки
3a18c32 Предыдущие и безусловно тоже хорошие правки [origin/develop]
Не отправлять же такое на сервер? А вот и не придётся.
Мы можем объединить последние два коммита в один, и дать ему хорошее название.
Сделать это очень просто: нам нужно мягко откатиться до коммита, который предшествует нашим неоконченным правкам и затем сделать commit. Вот и всё.
|
1 2 |
git reset --soft 3a18c32 git commit |
Вместо 3a18c32 подставьте хеш последнего коммита, который был до тех, что вы хотите объединить.
Стоит помнить что это изменение истории. Другими словами, если вы уже сделали push своих недоделанных правок на сервер, то менять их крайне нежелательно.
Одним из недостатков rebase является то, что при неумелом разрешении конфликтов (особенно в бинарных файлах), можно потерять нужную версию файла. Ещё один хороший способ потерять коммит, это удалить ветку, в которой он находится.
Do not panic!
В случае git, “потерять” — это не совсем верное слово. Git хранит последние коммиты, которые больше не находятся в истории, но ещё могут быть туда возвращены.
И так, предположим, мы сделали что-то не так и “потеряли” файл или целый коммит.
SQLite — компактная встраиваемая база данных, идеально подходящая для простых задач, вроде хранения игровых уровней или настроек приложения. Подробнее узнать об этой базе данных можно, например, тут.
Сама библиотека написана на Си, поэтому для её использования неплохо иметь под рукой более-менее удобную объектно-ориентированную обёртку на C++.
Я привожу решение, которое использую для своих проектов. Оно охватывает только базовый спектр задач, но может быть легко расширено.
Пока у вас нет опыта работы над реальными проектами, вас не возьмёт к себе ни одна серьёзная компания.
Но вот незадача, гейм-девелоперов в России почти нигде не учат.
Так как же получить заветный опыт?
Пути, в основном, два:
Выбор варианта зависит от того, кем именно вы хотите стать и где работать.
Если вы хотите разрабатывать игры для социальных платформ или игры жанра Logic/Puzzle, то вполне можно попробовать сделать проект в одиночку.
В случае, если вы хотите разрабатывать трёхмерные игры, особенно RPG, FPS, или же сетевые игры, то стоит для начала поучаствовать в разработке чужого проекта.
Часть 1: Первый реальный проект
Часть 2: Вступление в команду
Тут описывается лишь моё мнение, которое может иметь достаточно посредственное отношение к реальности.
Однако, оно может дать некоторую полезную информацию для тех, кто только знакомится с системами контроля версий.
Рассматриваются SVN, Git, Mercurial, Perforce.
Разрабатывая собственную игру, рано или поздно приходится задумываться о таком способе размещения объектов на сцене, при котором инфорацию о сцене можно будет хранить во внешнем файле.
На первоначальном этапе разработке вполне нормально увидеть в игре такой код:
|
1 2 3 4 5 6 |
... world.Insert(new Wall(Vector2D(250, 300), Vector2D(80, 20))); world.Insert(new Wall(Vector2D(250, 200), Vector2D(80, 20))); world.Insert(new Wall(Vector2D(200, 250), Vector2D(20, 80))); world.Insert(new LightEmitter(Vector2D(230, 450))); world.Insert(new PlayerSpawnPoint(Vector2D(230, 450))); |
Однако, рано или поздно игра вырастает больше чем в техническую демку и нам будет нужно редактировать уровни чаще чем код. Так или иначе, нам придётся хранить уровни в каком-то внешнем хранилище, будь то база данных, xml-файлы или же бинарные файлы своего формата.
Дело ясно: нам нужен менеджер уровней, который будет считывать данные об объектах из внешнего хранилища и создавать их на уровне.
Звучит просто, но на деле есть одна неприятная проблема: для того чтобы была возможность создать объект по идентификатору, менеджер уровней должен знать конструкторы всех создаваемых классов и иметь возможность выбирать из них нужные.
Бывают ситуации, когда нужно получить из репозитория большие правки по очень узкому каналу связи. Это может стать большой проблемой при периодических разрывах связи.
Git скачивает изменения потоком, никакие Download Master’ы тут не помогут. Казалось бы.