Автор: Илья Синицын
Контент зависит от интересов подписчиков. Миссия сообщества: создание open-source кроссплатформенного движка на C++. Как и любая более-менее нормальная миссия - почти не выполнимо... Предлагайте темы! :)
28 ноября 2014
1) Асинхронная загрузка ресурсов
2) Data Oriented Design, Entity-Component system
3) Евенты, Скриптинг (lua, python)
4) AI-system. Ползающие по Катмолу-Роме, стиринг и прочее из Programming Game AI by Example
5) UI
6) Партиклы, тира CreateParticle(TYPE, Pos1, Pos2, Easing, void (*callBack)(void))
7) Анимации, типа CreateAnimation(Object, Easing, t_params, void (*callBack)(void)), t_patams = (f_time, pos_begin, pos_end ...)
Чтобы можно было сделать полноценный Тауер Дефенс какой-нибудь.
1) Причины по которым следует отказаться от кросс-платформы.
2) Профит связанный с тем что создатели вовремя отказались от кросс-платформы.
3) Мизерная вероятность того что все-таки следует подумать над кросс платформой: основной передовой билд на основную целевую платформу и отстающие по функционалу билды на вторичные платформы.
// Чтобы можно было сделать полноценный // Флаппи бердз.
Собственно отвечу кратко, если окажется что этого не достаточно, то возможно напишу статью.
lookid
>>1) Асинхронная загрузка ресурсов
Собственно тут всё проще, чем кажется на первый взгляд: надо всего лишь то начать грузить эти самые ресурсы в другом потоке, а в основном ждать (например, ждать вызова callback, заданного при начале загрузки) окончания загрузки. Есть ньюансы, например, под iOS есть некоторые, легко решаемые, сложности при создании не в основном потоке ресурсов, относящихся к рендеру (текстуры, шейдеры, буфферы) и есть большие сложности с этим же под Android. Так же система потоков в движке или иная подсистема должна уметь давать команду из дочернего потока вызвать callback в главном потоке, но это делается не сложно через вектор callback'ов, в который добавляют callback'и дочерние потоки, а вызывают эти callback'и в главном потоке (обращение к самому вектору защищается критической секцией). Это пример самой простейшей реализации.
>>2) Data Oriented Design, Entity-Component system
Не адепт этих сект, ни плохого, ни хорошего сказать не могу.
>>3) Евенты, Скриптинг (lua, python)
Есть только положительный опыт использования lua, питон считаю избыточным для игр, но он даёт больше возможностей, так что всё зависит от поставленных задач. Собственно не понятно в чём вопрос? Если возникли идеи о том, чтобы использовать скрипты, скорее всего надо использовать!
>>4) AI-system. Ползающие по Катмолу-Роме, стиринг и прочее из Programming Game AI by Example
К сожалению не обладаю достаточным опытом в этом вопросе тоже.
>>5) UI
Это очень сложный вопрос на самом деле... Приходилось использовать множество систем, но везде самая большая проблема - интеграция с игрой... Тут на самом деле одной строчкой не отделаешься, но для написания статьи у меня нет готового хорошего решения... В текущем положении дел я бы посоветовал определиться со списком требований к системе UI и либо, если ооочень сильно повезло и нашлась подходящая готовая система - взять её, либо исходя из своих потребностей писать свою.
>>6) Партиклы, тира CreateParticle(TYPE, Pos1, Pos2, Easing, void (*callBack)(void))
Можете считать рекламой, но я считаю, что на данный момент для небольших игр нет ничего лучше чем MagickParticles.
>>7) Анимации, типа CreateAnimation(Object, Easing, t_params, void (*callBack)(void)), t_patams = (f_time, pos_begin, pos_end ...)
Тут вопрос в том, о какой анимации идёт речь и каким образом и кто её создаёт (в редакторе или кодом)?
lookid
>>1) Причины по которым следует отказаться от кросс-платформы.
Если планируется выпускать игру только под одну платформу - следует отказаться от кросс-платформенного движка, других причин я не знаю.
>>2) Профит связанный с тем что создатели вовремя отказались от кросс-платформы.
Профит смотря для кого. Профит для разработчика игры на этом движке - его особо нет, если движок написан хорошо и платформы похожи. Например, игра делалась под винду, а потом вдруг решили сделать такую же игру под iOS, причём поддерживать, например, поворот экрана девайса - то да, можно огрести. Но если список платформ сразу оговорен и не меняется, то проблем у разработчиков игры из-за разных платформ быть не должно.
Вот профит для разработчиков движка... да, его тоже нет! Если движок пишется свой, то получается под каждую платформу придётся писать свой двиг, если для экономии времени используются один и тот же код в разных движках, то по сути эти части уже являются частью кросс-платформенного движка... А если под каждую платформу готовые движки, то не понятно, почему бы не взять сразу готовый кросс-платформ двиг?
>>3) Мизерная вероятность того что все-таки следует подумать над кросс платформой: основной передовой билд на основную целевую платформу и отстающие по функционалу билды на вторичные платформы.
Что значит отстающие по функционалу? Кросс-платформ предполагает возможность собирать один и тот же код игры без изменений сразу под все поддерживаемые платформы. Есть только передовой билд и он сразу под все платформы.
Нет, ну есть люди, которые любят платить за одно и то же по нескольку раз, так вот кросс-платформ не для них, да.
Ладно-понятно.
Объясни тогда еще чего-нибудь про лицензии
GPL - ...овно?
MIT - круто?
CC0 - ?
зы. И если можно пример того как я могу прикрутить doxygen к моему "hello world" праЭкту. Или вообще про автоматизацию с документацией что скажешь.
codingmonkey
http://lmgtfy.com/?q=GPL
http://lmgtfy.com/?q=MIT
Про CC0 - надо ссылку?
Про автоматизацию с документацией... Я считаю, что код должен быть написан так, что писать для него отдельную документацию необходимости просто нет. Но это практически невозможно, так что я за автоматическую документацию. Но с документацией возможны проблемы не обновления документации при изменении кода, так что за этим надо пристально следить, иначе от документации будет больше вреда, чем пользы. Хотя с автоматической документацией это делать проще, чем с полностью рукописной документацией. С другой стороны есть некоторые проблемы со сразу несколькими переводами документации на несколько языков...
Но, собственно, ок - ссылка на репозиторий удалена, пока не будет принято решение собственно начать писать этот самый freeengine...
>Про CC0 - надо ссылку?
Да давай.
А что насчет систем контроля версий, с зеркальными копиями на основных таких системах ?
Может быть чего-нибудь расскажешь про билд-ботов для автоматической сборки под разные платформы ?
Git всем устраивает.
Не совсем понятно зачем нужен билд-бот? Если для разработчика, то у него может возникнуть такая необходимость в основном для того, чтобы убедиться в том, что написанное под VisualStudio компилируется под clang или gcc. И как правило то, что скомпилировалось Microsoft'овским компилятором и Gcc, то наверняка скомпилируется и Clang. Сборку проекта в студии можно реализовать из командной строки через msbuild. Сборку под Android из-под винды так же можно делать с командной строки. Под Mac так же можно собирать с командной строки проекты через XCode и Andoid проекты. Но разработчику обычно надо запустить с отладчиком то, что только что собрано, по этому не понятна цель билд-ботов. Вот для QA билд боты по идее не помешали бы, но достаточно и возможности собирать всё shell/batch скриптами с минимальным вмешательством и без необходимости знать IDE. Очень в этом плане жду VisualStudio 2015 - добавят возможность разработки под Android (используя Clang в качестве компилятора).
Build-bot - это удобный сервис обеспечивающий и гарантирующий что как минимум активная версия определенного источника разработки будет иметь бинарные пакеты для всех платформ всех используемых модулей. Меньше заморочек с полной пересборкой - на 30 раз компиляции под все платформы в ручную поймеш, что нужна автоматизация с авто компиляцией на помощь придет Build-bot. Для отладки в этом случае требуется пересобрать только отдельный программируемый модуль. В целом помогает сосредоточиться на чем то одном. Основная цель автоматизация.
А на кой все это?
foxes
>А на кой все это?
Ты опять не спишь ?)
Ну понимаешь, есть резон спросить человека о тех вещах в которых ты вообще еще не разбираешься, чтобы понять по ответу насколько он в теме и опытен.
И вместе с тем понять насколько он действительно собрался или может писать двиг.
the_siv
А что там насчет рейкастов и физики? Ты ее тоже хочешь самостоятельно писать, или сторонние фришные решения пользовать ?
Реальнее всего запилить 2д движог на Qt/qml с упором на инструментарий: редакторы мира/анимаций и пр + интеграция в иде qtcreator $)
Лучше всего делать модульным со слабым связыванием.
Позиционировать на моб. платформы.
Лицензия MIT,BSD, Apache - для комьюнити версии + платная с поддержкой и доп плагинами: монетизация, реклама, аналитика.
foxes
Как правило над проектом работает несколько человек, под разными платформами... Но я не говорю, что билд-бот не нужен, если кому-то нужен, то для его автоматической реализации достаточно просто как-то сказать удалённой машине запустить выше описанные скрипты и иметь возможность посмотреть логи. Скрипты писать приходилось, ботов не было необходимости. Но если человек один пишет игру, то несомненно ему очень помогли бы эти самые билд-боты.
>>А на кой все это?
Ну не тролля же покормить... Может кто-то почитает эту ветку, найдёт ответы на интересующие его вопросы.
codingmonkey
Физический движок - это очень сложно. Подходы вроде простые, но чтобы оно всё работало быстро и стабильно сделать на самом деле очень сложно и работы очень много. Не планировал вообще заниматься физикой, переложив эти заботы на программиста игры.
TrashCoder
Идея хорошая, единственное не понятна роль Qt во всём этом... Если взять за основу Qt, то это уже будет не движок, а надстройка над Qt.
the_siv
>переложив эти заботы на программиста игры.
Эм... программисты как раз другого мнения. Они не хотят заморачиваться с физикой.
Ну что это за двиг без физики ? А звук и сеть тоже забота программиста игры ?
TrashCoder
>Позиционировать на моб. платформы.
Печаль же. Имхо оnly PC православнее.
>Qt/qml
Чей та ?
Тема в архиве.