Comments 50
Исходники покажете?
Ну и без C++11 писать это боль все-таки.
Долго весь движок писали? Один?
Ну и без C++11 писать это боль все-таки.
Долго весь движок писали? Один?
Целиком исходники не покажу, но отдельные модули буду скидывать в след. статьях. Например модуль ReplayKit и модуль для захвата видео игры под OSX (при чем 1080p 60fps, что помогло в создании промо-видео к игре), выложу полностью. Да, писал один. Последняя глобальная переделка движка была в 2014г. В посте ниже подробнее описал историю создания движка.
Сначала прочитал статью по диагонали, думаю, а где название фреймворка, не уж то наш Marmalade SDK упомянули в кое то веки. Почти все есть из выше написанного. Если сделали сами — врете, нерельно, команда — возможно, но откуда финансирование? Если первое — то откуда опен-сорс базу взяли и потом на ней писали? И т.д.
О Мармеладе слышал много хорошего (с ним много работает дружественный мне издатель), но сам с ним не работал. Делал все действительно сам, и это не мудрено, если занимаешься мобайлом с 2008 года и за плечами порты игры Race illegal: High Speed 3D на J2Me, iOS, OSX, Android, WP8, Tizen и недавно еще tvOS добавился, правда для другой игры (та что в шапке и о которой будет отдельная статья). Движок родился в процессе разработки, был несколько раз переделан с нуля, а финансирование — мои же игры, на этом же движке.
Так а движок опен-сорс? А то толку от статьи пока никакой и попахивает самопиаром ;-)
Движок закрытый. Это первая часть серии статей. Следующие статьи будут разные, не только о движке. Например про шейдер катающейся капли напишу, а так же про левел-билдер на WebGL. И вообще буду рад написать обо всем, что люди попросят описать подробнее в каментах. Так что это не пиар, надо куда-то слить знания, а то голова пухнет :)
Однозначно плюс в карму. Но зачем заниматься вилосипедостроительством в 2016 году…
Вопрос. Легко ли можно писать под любой IDE? Ну т.е. у меня винда к примеру, девайс WP… у коллеги iOs и xcode, а у другого адроид. Мы легко можем вместе работать над одной игрой? Или основная разработка ведется только в одной оси и в одной IDE?
Можно заюзать cmake для генерации прожект файлов для любой IDE. В итоге можно будет пилить одну кодобазу с разных ОС
Да, вполне легко. Собственно тестируя игру под разные платформы, вы в любом случае запускаете разные IDE и собираете проект там. При этом сам код и ресурсы игры единые. Ну почти единые, конечно для телефона и телевизора будут отличия и в управлении, и в UI. Но эти отличия спокойно помещаются в одном .cpp файле.
Лично я 80% времени тестирую и пишу игру под OSX (именно запускаю собранную игру), по простой причине — скорость компиляции и запуска. Когда запускаешь игру по 20 раз в час, то скорость запуска сильно бережет нервы.
К тому же под OSX могу менять размер окна и сразу видеть как игра смотрится на телефонах и планшетах разных размеров, ура резиновым интерфейсам. На самих девайсах же запускаю более детальные тесты, например отладить чувствительность управления гироскопом и т.д.
Лично я 80% времени тестирую и пишу игру под OSX (именно запускаю собранную игру), по простой причине — скорость компиляции и запуска. Когда запускаешь игру по 20 раз в час, то скорость запуска сильно бережет нервы.
К тому же под OSX могу менять размер окна и сразу видеть как игра смотрится на телефонах и планшетах разных размеров, ура резиновым интерфейсам. На самих девайсах же запускаю более детальные тесты, например отладить чувствительность управления гироскопом и т.д.
Личнчо мне интересно было бы почитать про рендереры на вулкане+металле :-) 2016ый год же, как тут заметили в комментариях.
Как вы вообще сделали нормальную кроссплатфомерную сборку такого большего проекта? Полагаю cmake, но как нужно наишачить его, чтобы нормально устанавливать зависимости (взять к примеру тот же libwebp). Как это все дело нормально прикрутить к cmake, чтобы скорость билда была нормальной, а библиотеки были нормально и кроссплатформерно прикручены. Да никак уже не могу нормально настроить эту фигню.
P.S. Смотрю в сторону conan, может что-то с ним получится. Если быть точным, ещё сложности с luajit, который компилируется Makefile'ами на никсах, а на остальных (всякие консоли, Windows) — скриптами.
P.S. Смотрю в сторону conan, может что-то с ним получится. Если быть точным, ещё сложности с luajit, который компилируется Makefile'ами на никсах, а на остальных (всякие консоли, Windows) — скриптами.
Почему адмоб не значится в списке рекламных модулей? :)
OpenGL 2.0? В 2016? Вы серьёзно?
В своём движке на D я использую OpenGL 4.5. На мобильные платформы ещё не портировал, но OpenGL ES 3.0 более-менее совместим.
Но пока это малоприоритетно, т.к. основная аудитория — пользователи ПК.
В своём движке на D я использую OpenGL 4.5. На мобильные платформы ещё не портировал, но OpenGL ES 3.0 более-менее совместим.
Но пока это малоприоритетно, т.к. основная аудитория — пользователи ПК.
ES 3.0 процентов у 60 юзеров будет.
И игра ваша не запустится у большинства десктопных юзеров. GL 4.5 это GTX400 и выше. Успехов с чем нибудь вроде Intel HD
Ну а вообще, выпендриваться что вы пишете на языке с сырой экосистемой под недавно появившийся стандарт — удел школьников, которые как правило ничего не довели до конца в своей жизни. Тут статья о реальности.
И игра ваша не запустится у большинства десктопных юзеров. GL 4.5 это GTX400 и выше. Успехов с чем нибудь вроде Intel HD
Ну а вообще, выпендриваться что вы пишете на языке с сырой экосистемой под недавно появившийся стандарт — удел школьников, которые как правило ничего не довели до конца в своей жизни. Тут статья о реальности.
Есть замечательная штука — steam hwsuvey. Пользователей со старыми видеокартами очень мало. К примеру HD5000 от AMD поддерживает 4.5 и вышло в 2009 году. Я думаю, за 7 лет можно обновить видеокарту.
С картой старее — в любую более-менее современную игрушку играть невозможно.
Что касается встроек — они как бы не для игр. У Intel поддержка OpenGL всегда была никчёмной.
Ах да, игра выходит в мае в бету. Движок полноценно поддерживает тени, освещение, постпроцессинг, геометрические и тесселяционные шейдеры. Напишу статью :)
Реальность — это о том, что нужно писать на стандарте, который вышел 15 лет назад? Серьёзно, 2.0 вышло в 2001 году.
С картой старее — в любую более-менее современную игрушку играть невозможно.
Что касается встроек — они как бы не для игр. У Intel поддержка OpenGL всегда была никчёмной.
Ах да, игра выходит в мае в бету. Движок полноценно поддерживает тени, освещение, постпроцессинг, геометрические и тесселяционные шейдеры. Напишу статью :)
Реальность — это о том, что нужно писать на стандарте, который вышел 15 лет назад? Серьёзно, 2.0 вышло в 2001 году.
Ок, смотрим Apple Hardware GPU Information. Например iPad 2 не поддерживает OpenGL 3.0 и далеко не во всех играх нужна тесселяция. Поднимать версию без веской причины не вижу смысла.
UFO just landed and posted this here
HD5000 поддерживает 4.4,
4.5 — это HD7000, это ~4 года.
4.5 — это HD7000, это ~4 года.
Мой старый Android худо-бедно 2.0 поддерживает, а вы про 4.5…
Извините конечно, а у вас точно движок? Почему основной части уделена одна строчка Classes (.h, .cpp файлы движка)?
А как же такие глобальные вещи как рендер, физика и логика? Мне хочется понять, что именно вы написали помимо поддержки разных платформ и социалки. У меня к вам по каждому пункту куча вопросов. Давайте возьмем самое простое «Чтение/запись файлов.». Стриминг у вас есть?
А как же такие глобальные вещи как рендер, физика и логика? Мне хочется понять, что именно вы написали помимо поддержки разных платформ и социалки. У меня к вам по каждому пункту куча вопросов. Давайте возьмем самое простое «Чтение/запись файлов.». Стриминг у вас есть?
Вы абсолютно правы, именно в Classes находятся самые главные файлы. В одну статью все не поместилось, буду конкретизировать в продолжениях.
Например для симуляции использую физику верле. Рендер оптимизирует смену стейтов, занимается камерой/проекциями, группами, подбором нужного шейдера и его настройкой.
«Чтение/запись файлов» упрощает работу с fopen, fread, fwrite и т.д. Из полезного — расшифровывает файлы, понимает по каким путям где что лежит, читает ресурсы непосредственно из apk. Стриминг (fstream) не использую, как-то не нужен нигде был.
Например для симуляции использую физику верле. Рендер оптимизирует смену стейтов, занимается камерой/проекциями, группами, подбором нужного шейдера и его настройкой.
«Чтение/запись файлов» упрощает работу с fopen, fread, fwrite и т.д. Из полезного — расшифровывает файлы, понимает по каким путям где что лежит, читает ресурсы непосредственно из apk. Стриминг (fstream) не использую, как-то не нужен нигде был.
Ну тогда на правах коллеги позвольте вас попытать для обмена опытом ) По рендеру, у вас есть система частиц, лоды, террейн рендеринг, порталы, костевая анимация, деколи? Столько вопросов по реализации )
Буду рад, пытайте :) Частицы использовались в нескольких проектах, а значит пора их выносить в модуль. Лоды, скелетная анимация и горы тоже были, но только в одном проекте, поэтому пока выносить их в движок не спешу. Стоит уточнить, что у меня нет задачи создать универсальный движок. Появляются новые проекты и моя цель максимально ускорить процесс создания игры с минимальным портированием.
Пожалуй mainloop — это самое важное, что есть в основном классе. Именно там происходит управление fps, обработка тачей/кнопок, выполнение тасков в основном потоке (особенно для OpenGL без shared context актуально и изменений UI из фоновых потоков), поддержка слоев (аля окна), смена стейтов приложения (меню/уровень/магазин/.../лоадинг скрин). Видимо это еще одна тема для статьи :)
А зачем писать именно с нуля? Есть так хочется своих кастомных вещей в движке, то почему бы не взять открытый существующий и просто менять/расширять его как душе вздумается?
Где можно посмотреть на игры сделанные на этом движке? А то может там тетрис или flappybird :)
Такой вопрос, кстати. Известно, что в играх порой очень сложно обойтись без скриптов, увеличивающих гибкость движка. И как с этим на iOS, где любые интерпретаторы запрещены? lua, так понимаю, не используешь?
Особой необходимости в скриптах пока не было. Вернее, уровни созданные в левел-билдере на webGL конвертировались в логику на С++. Но это была внутренняя логика игры и в движок ее не выносил. Если понадобятся в будущем скрипты, то буду использовать Lua. В AppStore вроде использовать Lua не запрещено.
А если я, к примеру, получаю от сервера команду на установку определённого уровня пользователю, будет ли такой трюк считаться нарушением? К примеру, у меня на сервере логируется игра пользователя и бекапится текущий прогресс. Если пользователь случайно потерял прогресс, я могу восстановить его с сервера. Как они к такому отнесутся?
Такое вполне допустимо и встречается почти во всех SDK. Например:
- save/load прогресса на своих серверах
- сегментация игроков для кастомизации игры (покупающим игрокам показываем один магазин, остальным — другой)
- проверка in-apps на сервере (при обнаружении взлома имеет смысл обнулить прогресс игрока)
- A/B тестирование
- загрузка/обновление конфигов/уровней
и т.д. в общем общаться с сервером и от этого подстраивать игру под игрока, очень даже приветствуется и используется повсеместно.
Да собственно, и интерпретатор lua не запрещен. Запрещены jit компиляторы, причем на уровне sdk, у вас просто не получится их запустить. К примеру luajit будет работать в режиме интерпретатора (хотя все равно в 5 раз быстрее чем оригинальный lua интерпретатор)
Если вы будете скачивать скрипты на Lua из интернетов и запускать — тогда эпл имеет право вас забанить (есть в апп сторе такой пункт), а так — на здоровье.
ЕМНИП запрещено интерпретировать код, загруженный в обход аппстора. Если интерпретируемый код содержится в бандле приложения, то проблем быть не должно.
так или иначе — это все равно велосипед от гиков и для гиков,
А почему об Appodeal возникло такое мнение, что это недобросовестная компания?
Sign up to leave a comment.
Как это сделано: мобильный кроссплатформенный движок