Comments 48
Вот я чего не пойму. Игровая логика, она же как правило мудрёная. А зачастую очень и очень мудрёная. Но игровые движки предлагают описывать эту логику на языках с динамической и слабой типизацией. Хотя казалось бы, чем строже язык, тем удобнее на нем описывать сложную логику. Злой в плане типизации Haskell справляется с очень развесистой логической клюквой. Но движки как будто соревнуются, кто предложит язык с как можно менее строгой типизацией.
Кто ни будь пробовал на Lua писать игровую логику? И как оно вам?
Яп для написания логики в движках, выбирают по другим характеристикам, как сложно его интегрировать в движок (например, lua легко и быстро интегрировать в игровой движок на плюсах), как дружит с различными платформами, как сильно влияет на билд игры и т д.
По поводу написания логики на Lua. Могу порекомендовать игровой движок defold. Писать на lua одно удовольствие.
Я думаю, что нет никаких проблем в динамической типизации, если ты не выбираешь движок под AAA-игру.
Зависит от игры. Порой достаточно и визуально-блоксхемного программирования(которое, кстати, несколько лет назад завезли в тот же анриал).
Так что всё, как всегда, упирается в скорость разработки прототипа и трудозатраты допиливания его до конечного продукта.
Шок контент конечно, а потом на хабре выходят статьи с 1к+ комментов о там как деградировало современное ПО.
Как по мне если ты НЕ соло пилишь свою игру, или вообще делаешь проект онли для себя, то за те самые блюпринты и использование дин типизации нужно выгонять нафиг из сферы деятельности, а потом еще и по рукам бить, до синяков
Может быть если бы так было - игры бы не стали полнейшим ужасом в плане оптимизации, что происходит со всеми последними релизами.
Блюпринты ускоряют разработку и снижают порог вхождения. Как следствие - уменьшаются затраты. Следовательно - быстрее можно выйти на рынок.
Так что в плане компаний как раз, что лепят игры однодневки ну или у кого конвеер по производству - это лучшее решение.
Уже потом можно переписать целые модули на код, если взлетело и нужна производительность.
Тут рулит менеджмент и планы продаж...
Полагаете, что ресурсы съедает именно логика игры, а не рендеринг? И если код логики типизировать, то станет существенно быстрее?
Есть разные игры. Имхо, первый коммент вообще некорректен, в подавляющем большинстве игр логика проста как лом. Десяток условий на боссах, дерево выборов в диалогах - ничего затратного с точки зрения вычислений. Есть, конечно, 4Х стратегии, типа Виктории, где подглагивания можно было бы объяснить тем, что вычислений там действительно уйма. Но таких игр можно пересчитать по пальцам.
А в лагучих релизах проблемы чаще могут лежать вообще где угодно, в ui, в физике (где вычислений тоже может быть тонна), в сетевом коде...
Игровая логика в полноценных рпг с большой квестовой составляющей и всяких стратегиях, особенно экономических сложна. Во всяких аркадах и т.п. конечно довольно примитивна.
Другое дело что принято забивать на игровые баги, считая их чем то само собой разумеющимся. А потом происходят косяки с невыполнением квестов, потому что ключевой персонаж мертв, ключевой предмет утерян и т.п. И отловить их можно только в рантайме, а не на этапе компиляции.
World War 2 сильно начинает тормозить в процессе игры именно по причине сложной логики. Вообще это присуще 4X стратегиям. Stellaris и Endless Space тоже начинают подтормаживать к лейту.
Простите, но зря вы так с не- и слабокодящими геймдизайнерами. Игры и так в последнее время превращаются в корпоративный шлак, а вы хотите выгнать из индустрии часть людей, которые всё ещё пытаются привнести в неё креативность, из-за собственной не слишком объективной ненависти к использованому подходу.
Не надо так. Будьте человечнее. Идеи не стоят того, чтобы бить людей.
Кто ни будь пробовал на Lua писать игровую логику? И как оно вам?
Ещё как пробовал. Не могу сказать, что это прямо приятное занятие, но явно комфортнее визуального программирования блюпринтами в духе UE. И не требует пересборки проекта после каждого изменения, нужный скрипт можно перезагрузить на лету. UE сейчас предлагают использовать Verse как промежуточный этап, но с его синтаксисом я, пожалуй, пас.
Я писал на луа скрипты для вова. Вполне удобно было. Большим плюсом был низкий порог входа, поэтому многие новички легко вкатывались в написание/редактирование скриптов.
Писал, и тут сильно зависит от архитектуры луа составляющей. Когда луа в кокосе был second class приходилось делать собственную архитектуру и гайдлайны как-то продвигать, было не очень. Когда плюсовую инфраструктуру продублировали - стало проще, хотя и несколько проблемно ловить некоторые баги.
Вне кокоса тоже было неплохо, но там логика крутилась на миксинах и хвала байтам мне не приходилось с ними возиться.
Игровая логика как правило очень слабосвязанная. Сегодня инвентарь есть у песонажа, завтра инвентарь это сундук, после завтра инвентарь добавить в машину. Практически каждый объект может взаимодействовать с другим, куда тут уж статическая сильная типизация? Наоборот чем слабее типизация тем удобнее. Тот-же ecs который захватил геймдев во многом про слабые связи между объектами и про то что объект можно собрать из различных компонентов, которые к тому-же будут изменятся во времени. Не имел опыта с хаскель, но игровую логику я бы писал на чем угодно, но не на моём любимом cpp.
В течение многолетнего периода пользовались реализацией LuaJIT. И считаю это наверное один из лучших существующих языков для данной задачи. Что не удивительно, ведь он специально проектировался и создавался конкретно для ее решения.
Почти ничего не весит, элементарно встраивается, быстро учится даже не программистами, не скуден возможностями, удобный биндинг, крайне производительный, успевает запуститься, отработать, и вывести результат раньше чем я подниму палец с клавиши запуска. Главный минус - маленькая встроенная библиотека, но именно такая и должна быть во встраиваемом языке.
Что касается логики, то flavor мудрености игровой логики, и flavor сложной логики которую удобно писать на статических языках - это два разных flavor'а. Не видел еще ни разу, чтобы статический язык сам по себе помогал исправить например блокирующий прогресс баг в логике ветвленной цепочки квестов. При этом подавляющая часть игровой и квестовой логики это элементарщина. А если нужен сложный алгоритм - он пишется на основном языке и биндится.
Писал когда то давно логику на Lua, особых проблем не испытывали - и порог входа низкий, и производительность достаточная. Но и игры там были в стиле Hidden Object, так что никаких мудреных алгоритмов не требовалось. Сам движок, естественно, был написан на плюсах.
Знаю примеры, когда LUA в юнити внедряли для скриптинга определнных частей игровой логики типа катсцен и т.д
С работой в России на данном движке туго. Сам года 2 назад работал в Playgendary как джуниор разработчик - делал Playable Ads. Но вот после работу на этом конкретном движке так и не нашел. На всех вакансиях, по ощущению, хотели сразу миддл+/сеньора, но на мой взгляд, предлагали ниже рынка, и дообучать меня не хотели от слова совсем, даже с учетом 1 года реального коммерческого опыта
Про Cocos понятно, лютый Китай - называет себя кроссплатформенным но загрузки кроме как на Windows я не обнаружил. Может и хорошо для сетевых дел.
А с Defold ничего не понятно, всё бесплатно и они ещё сборочный сервер держат - откуда деньги? Или иначе - как они будут меня продавать?
называет себя кроссплатформенным
собирали как под Айфоны с Андроидами так и на десктопе запускали во время разработки (Win/Mac/Linux). Единственное, что для десктопов использовать кокос сомнительная затея, хотя вполне реальная.
Cocos Creator работает ещё под MacOS.
А с Defold ничего не понятно, всё бесплатно и они ещё сборочный сервер держат - откуда деньги? Или иначе - как они будут меня продавать?
И как можно было предположить что я этого не читал? Ну получили донат, теперь живут якобы на подачки и не собираются зарабатывать. Так не бывает. Корпоративное спонсорство? Чего ради? Наблюдать за активностью игроделов, при этом имея возможность прекратить её отключив единственный сервер? Зачем?
Это ещё более загадочно чем с Гуглом - тысячи тщательно отобранных инженеров собираются в одном месте и в условиях превосходящей Манхеттенский Проект секретности ежегодно выпускают не вполне рабочий смартфон... Бывает так?
Спроси в этом чате, там не только разработчики игр, там ещё сидят разработчики defold.
А если сравнивать с Godot?
Он вроде как тоже может в web, open source, свой скриптовый язык или C#... В общем интересно ваше мнение, если был какой-то опыт.
это фреймворк, который перестал обновляться в 2019 году
откуда дровишки? последние коммиты за сим годом значатся. В планах там и 4 версию выпустить были, правда неизвестно насколько она бета получилась.
Сейчас актуален Cocos Creator.
Фактически это просто студия, аналогичная Unity. Cocos2d-x как движок никуда не делся, просто генерация кода для однообразных механик становится более унифицированная. Ну и сборка под платформы проще (по крайней мере планировалось).
Ubisoft, Gameloft, Square Enix, FunPlus, Tencent
Сами кампании этим не пользуются. Пользуются их купленные кампании, занимающиеся мобильными играми.
Не так много работы.
Потому что надо искать Lua/C++ программистов, а не фреймворкистов - чай не js. После СВО в России в принципе геймдева не так много осталось, это не связано с популярностью фреймворка.
Это самый мощный игровой движок
Движок изначально затачивался под 2д на мобильных платформах, поэтому куски легаси тянутся ещё со времён когда оно было cocos2d на objective-c
Легаси очень сильно влияет на производительность - на одной из прошлых работ коллега делал серьёзные доработки графического пайплайна, чтобы FPS было таки в районе 60, а не 30. Серьёзно дорабатывалась система управления памятью - переписывался кокосовый аллокатор (AutoreleasePool) и избавлялись от встроенных кокосовых умных указателей, тянувшие бремя `auto_ptr`. Внутреннее устройство компонентов всё это время продолжает жить без ECS, включая js/ts. Так что LeoEcs скорее всего работает как замена того AutoreleasePool для веб, помогая с уменьшением фрагментации за счёт использования арен (но я тут свечку не держал, могу ошибаться).
Когда я последний раз пробовал запускать студию то огромное количество вещей просто не работало - даже генерация проекта. С появлением веб таргета вероятно что-то таки завелось, но с учётом размера их команды думаю прогресс не был достаточно значительным, учитывая количество поддерживаемых таргетов.
Поэтому не знаю как он у вас оказался "самым мощным", учитывая количество проблем с одной из главных состовляющих игр - графикой.
последние коммиты за сим годом значатся
Как-то это активным процессом разработки язык не поворачивается назвать. В обоих коммитах единственный измененный файл — readme.md
Это у них перманентное состояние, т.к. там буквально три китайца этим занимаются. Плюс поддерживают ещё околококосовые проекты а ля тех же блокчейн платформы для блокчейн же игр. И большая часть этих работ ведётся в закрытом режиме, поэтому апдейты в проекте не сказать чтобы прям супер активные.
коммиты в readme файл )))
но на самом деле вы не ту репу смотрите, за свежими коммитами сюда
https://github.com/cocos/cocos-engine
Во-первых, я смотрю в ту репу, которую указал сам автор комментария. А во-вторых, ваша ссылка это не cocos2d-x
Мне кажется cocos2d-x уже не относится к рассматриваемому предмету в статье, а именно COCOS CREATOR
Потому что я посмортрел и почитал:
cocos2d-x эволюционировал непосредственно в COCOS CREATOR и сама студия имеет в себе build-in движок для нативных билдов
Непосредственно сам движок, вроде как, расположен:
https://github.com/cocos/cocos-engine/tree/develop/native/cocos
А сама статьтя, как по мне статья в техническом плане не о чем ) и полезна лишь как популяризатор COCOS CREATOR
Я когда-то давно на cocos2d-x игры писал, достаточно хороший инструмент был. Какое-то ещё время следил за развитием COCOS CREATOR, потом забросил
Молодцы, конечно, ребята инструмент очень вырос, трансформировался непосредственно в целую платформу для игр!
https://docs.cocos.com/creator/manual/en/getting-started/introduction/
Cocos2dx и Cocos Creator это два разных движка. Где-то в глубинах их форума была запись, что cocos2dx-v4 - это последняя версия плюсового движка, и больше он не поддерживается. С графическими редакторами для него беда, к креатору его не подключить, FairyGUI использовать - это страдать. Последний специализированный редактор - CocosStudio, работает только на маке с Hight Sierra на борту (тоже страдания, только по другому).
Есть парни, которые форкнули проект и потихонечку переписывают. Пока надежда на них.
Только в README раздел есть
Therefore, we no longer recommend new users to start with Cocos2d-x. Instead, please use the brand-new Cocos Creator for project development to enjoy the best editor and 3D support.
Не рекомендуется, но и не умирает т.к. нативные платформы запускаются именно при помощи него. Веб версия скорее всего работает с cocos2d-js, который теперь наверное уже cocos2d-ts. То есть Creator это комбайн поверх двух с половиной движков плюс интеграции с кучей всяких систем - рекламы, сторы, аналитика и т.п - то есть не движок сам по себе. Это примерно как звать Android Studio движком для андроид разработки.
Studio мы когда-то даже использовали для создания сцен, проекты которого мы потом отдельно самостоятеьно парсили. Разрабатывалась правда емнип сторонними людьми, не основными контрибьюторами кокоса и да только под мак.
откуда дровишки? последние коммиты за сим годом значатся. В планах там и 4 версию выпустить были, правда неизвестно насколько она бета получилась.
https://docs.cocos.com/creator/manual/en/#product-line-overview
Сами кампании этим не пользуются. Пользуются их купленные кампании, занимающиеся мобильными играми.
Соглашусь.
Потому что надо искать Lua/C++ программистов, а не фреймворкистов - чай не js. После СВО в России в принципе геймдева не так много осталось, это не связано с популярностью фреймворка.
Частично соглашусь. Просто компании выбирают, тот же unity, ещё потому что найти специалистов легче, чем на Cocos Creator или тех, кто разработает движок для проекта. И частично это связано с образованием (как с курсами, так и университетами и т д), где в основном программы по разработке игр на unity. Иногда Unreal. А вот программы, где разбирали бы рендер, физику, ai и т д, как это работает более глубоко, и делали бы на плюсах, хотя бы не с нуля, а с использованием библиотек (суть думаю поняли), такие есть, но в рф их очень очень мало.
Поэтому не знаю как он у вас оказался "самым мощным", учитывая количество проблем с одной из главных состовляющих игр - графикой.
Ну тут смотря под какую платформу. Для пк unreal куда круче по графике будет.
Под веб в 3д, лично для меня, Cocos Cretor пока самый лучший среди 3д движков. Тому подтверждения (в то что графика может быть красивой и технологичной) демка Lake или cocos cyberpunk. Но игроку в веб играх, куда важнее скорость загрузки (этот пункт зависит ещё от типа игры и др. факторов), геймплей, стилистика графики.
Я писал статью с целью, что бы больше людей узнали про Cocos Creator. Просто у многих ассоциации с фреймворком cocos2dx, а кто-то вообще не слышал. Да, cocos не идеален, как и другие движки, всегда есть плюсы и минусы.
Спасибо очень интересно. А вот плагины для гугл плей\фейсбук\рекалмы для мобильных платформ как разрабытывать? Вроде у юнити полегче с этим, но я могу ошибаться.
Для монетизации под мобильные платформы, есть vungle. Сейчас тестируется Admob, который появится, когда выйдет Cocos Creator 3.8.
Плагин просто для гугл плей, тоже есть.
Vungle и плагин для гугл плей входят в cocos services.
С facebook точно проблем не будет https://docs.cocos.com/creator/manual/en/editor/publish/publish-fb-instant-games.html
Есть ещё статья, как добавлять android sdk в cocos creator
99% сторонних вещей предоставляют SDK под нативный андроид. А Creator выгоняет как раз проект в AndroidStudio.
Да, вам придется в общем случае написать мост между Java/Kotlin и JS.
Кокос кнчн хороший движок, спору нет. Но у него есть фундаментальный косяк - на мобильных платформах это по сути вебвью. Со всеми вытекающими последствиями в виде ANR, перерасхода ресурсов и прочего.
Не, там не вебвью. Там свой нативный рантайм против которого бандлятся js-ные скрипты.
Этот рантайм - кусок V8, который все и рисует ) Да, вебвью получается кастомный, не стандартный - но оттого проблем не становится меньше (
Нет, у вас неправильная модель в голове. Там прямо весь движок написан в двух версиях – на ts и на cpp. JS-машинка для скриптов, понятно, что есть. Но вот создаваемые ей объекты движка и сам рендер-луп – они в двух разных версиях для браузера и для натива. Соответственно, на нативе никакого "webview" и близко нет, есть некая "коробочка", из которой можно доставать уже оптимизированные спрайты и меши, а вовсе не WebGL-ный контекст.
Например, RenderScene:
https://github.com/cocos/cocos-engine/blob/develop/native/cocos/scene/RenderScene.cpp
https://github.com/cocos/cocos-engine/blob/develop/cocos/render-scene/core/render-scene.ts
На мобильных платформах отрадясь нативный код гонялся и рисовался через Open GLES. Вебвью там появляется только если веб версию собирать.
Пишешь код — Ctrt+S — зашел в Cocos — перешел в браузер — и уже запускается игра.
По этой причине и пересел на JS для пет-проджектов и геймдева. Минимум требований к системе разработки (VsCode+Chrome). Даже гайд написал. Очень подкупает простота разработки, скорость старта и скорость отклика при изменениях. Да и весят такие игры минимально. Эта моя игра весит 1014КБ без ассетов (и то я ее не оптимизировал по весу никак, даже внешняя либа не минифицированная).
Но, конечно без строгой типизации - туго. Тут либо TS, что требует предварительной установки как минимум nodejs. Даже сделал пак с быстрым развертыванием билда для фронта, чтобы авто-билдилось при изменениях.
Либо на голом JS, благо есть JSDoc 3. Но это все равно не очень удобно - код отдельно от описания. Классы не люблю, т.к. нужно писать this и вообще много лишних слов. Количество this в коде растет в геометрической прогрессии с ростом класса. В то время как return {property} - пишется один раз и в одном месте сразу видно публичную структуру объекта.
Пока что для себя вывел такой code style - VsCode его хорошо цепляет для intellisense без расширений. Может и костыльно, но работает. Инкапсуляция есть, полиморфизм есть, наследование через делегирование. Правда есть свои проблемы, JSDOC не подцепишь, рекурсивные функции не подцепляются, лишняя проверка на false и выглядит порой криво.
function createObject(name='myObject'){
const items = []
const obj = { name, appendChild }
return obj
//---
function appendChild(child = createObject()){
child.name += 'child of '+name
items.push(child)
}
}
const myObjects = false?[createObject()]:[]
Если говорить про заработок html5 игр, учитывая, что в этом году они показали спад, то движок, который ограничивает сторы, по моему не особо конкурентный, в сравнение с тем же Unity. Сервисы с готовым sdk, по типу gamepush, по моему не работают с кокосом и тогда кокос имеет смысл использовать для общего развития? А так статья интересная) P.S я только начинаю разбираться, не кидайте тапки)
Если говорить про заработок html5 игр, учитывая, что в этом году они показали спад
Cocos не ограничивается html5 играми. И в статье были примеры успешных игр на мобильные устройства.
Сервисы с готовым sdk, по типу gamepush, по моему не работают с кокосом
Это высказывание сравнимо с тем, что шарписту сказать, что в c# нельзя запускать процессы в windows.
У cocos есть одно ядро на ts для веб-платформ, и скрипты пишутся на ts. Поэтому, cocos куда ближе к html5, чем unity. Так что gamepush (или другие sdk и сервисы) внедрить не составит труда.
который ограничивает сторы
Какие сторы ограничивает?
Поддерживаемые сторы и веб порталы для сборки в Cocos Creator:
Cocos Creator — отличная альтернатива Unity, о которой вы, возможно, ещё не слышали