C0x>Ну например тем не устраивает что браузер это одна среда на все платформы. Мне плевать в прямом смысле этого слова где игра будет исполняться, для меня это одна среда-браузер.А в юнити нужно приседать и прыгать с бубнами чтобы под каждую платформу запинать игру. Под мобилы я уже вообще не говорю, там считай отдельная разработка обычно.
Если так напрягает, то можно зарелизить из Unity в WebGL и страдать в броузере на всех платформах. но обычно так никто не делает, потому что переключить build-target и нажать Build, народу пока не лень.
Re[4]: Разработка кроссплатформенной игры на web движках
O>Я думаю тебе хотели сказать про плагин от Unity под броузер. Т.е. пишешь на юнити и запускаешь в браузере через их плагин, помоему они используют WebGL, может сейчас еще что-то появилось.
Сейчас собираеться WebAssembly c WebGL. Работает нормально, плагинов не требует. Минус-время и обьем первой незакешированной загрузки — типичен для всех webassembly
Re: Разработка кроссплатформенной игры на web движках
Здравствуйте, C0x, Вы писали:
C0x>Товарищи игроделы!
C0x>Как вы рассматриваете перспективность разработки игры на браузерных движках?
самые лучшие двухмерки — это флеш-игры типа "механариум", "саморост", "субмашины", "туман" и прочие квесты. детям до 5 лет самое оно.
Re[2]: Разработка кроссплатформенной игры на web движках
Здравствуйте, ӍїϛϮϠǷiя-ȺҜ, Вы писали:
ӍȺ>Здравствуйте, C0x, Вы писали:
C0x>>Товарищи игроделы!
C0x>>Как вы рассматриваете перспективность разработки игры на браузерных движках? ӍȺ>самые лучшие двухмерки — это флеш-игры типа "механариум", "саморост", "субмашины", "туман" и прочие квесты. детям до 5 лет самое оно.
Самая лучшая двух пока это Марио.
Re[3]: Разработка кроссплатформенной игры на web движках
Здравствуйте, C0x, Вы писали:
C0x>Товарищи игроделы!
C0x>Как вы рассматриваете перспективность разработки игры на браузерных движках?
направление сверх перспективное, настолько что создало серьезную конкуренцию гуглу и эплу с их сторами...
Эпл там долго кочевряжилось с запретами интерпретаторов и запретом подкачки кодов из интернет,
гугл пошел на урезание и запрет многих фич важных для МОБИЛЬНЫХ игр — фоновый звук, авто-запуск видео и звука без инициации игроком,
запрет WebRTC камеры и даже обсуждается запрет акселерометра — типа по тапу по экрану и реакции акселерометра на это можно пароль узнать,
запрет на работу js в фоне, — то есть у гугла и эпла ДЛЯ МОБИЛЬНЫХ игр на JS путь на тотальное урезание всех игровых фич
чтобы они не конкурировали с их сторами и маркетами — это не предсказуемое бедствие падающее на голову совершенно неожиданно.
(утром работало, в обед уже не работает, алерты в сторе и удаление игр
— например недавно — алерт — вы ипользовали уязвимую версию jQuery — игра удалена и тд подобный бред от И-анализатора)
Нельзя как правило ипользовать — обфускатор — сразу алерты на подозрение на вирусы, причем чем лучше и более рандомизировано он работает
тем вероятнее ложное срабатывание гугловского анализаора в гугл-плэй
это все про МОБИЛЬНЫЙ мир — на десктопе имхо js уже победил в сегменте небольших и средних проектов да и даже больших типа те то на мэйл.ру-games
вообще ваш вопрос был актуален 3-4 года назад.
сейчас я бы ожидал от вас вопля типа: "А-а-а-а чо-о-о-о так можно было?!"
то есть иходя из вопроса вы все проспали
ну например так называемые mini-игры (там есть огромные клиент-серверные тоже) для мобильной апликухи ВКонтакте пишутся исключительно и только на JS
Здравствуйте, C0x, Вы писали:
C0x>Товарищи игроделы!
C0x>Как вы рассматриваете перспективность разработки игры на браузерных движках?
C0x>Речь идёт о том что изначально игру делать в браузере на каком нибудь babylon.js или three.js используя js или typescript. Для сети вебсокеты. А позднее когда игра готова оборачивать игру в electron или CEFSharp и издавать для десктопа в Стиме.
C0x>Логика моя такая: 1) браузер (canvas, webgl) уже на высоком уровне поддерживаются браузерами + есть движки хорошего уровня. 2) запоковать для десктопа тоже не проблема хоть для мобильной хоть для любой десктопной платформы. 3) делится вебной версией проще простого, кинул ссылку и все.
Делал коммерческие игры не меньше чем на десятке технологий. Сейчас свой бизнес перевёл таки на Юнити.
Комментирую из прочитанного в ветке:
1. Интерфейс верстать на ХТМЛ для игры не стоит. Это сильно сложнее чем мышкой в Юнити и выглядеть будет топорно. Игры это не совсем приложения.
2. Игры это много специфического кода. Быстрой физики, например, на JS не может быть принципиально. Только в ВебАссембли если.
3. Работа с графикой. В Юнити внятная система шейдеров со сборкой под любую платформу и прочее. Там реально большая работа проделана.
4. Поддержка конечных платформ это нудная рутина. Если можно заплатить 150 баксов в месяц и избавиться от этого на 95%, то так лучше и сделать.
5. Все JS движки не имеют хорошей расширяемой среды разработки. Приближается к этому только CocosCreator. Его я и использую если надо прям очень именно JS. Но на фоне Юнити он бледный конечно.
6. Недостаток у Юньки как в ВЭБе так и везде один — большой размер движка. Но в последние годы стало чуть лучше с этим.
В общем если надо именно игры делать, а не возиться с инструментарием, то выбора особо и нет. Но для опыта повозиться конечно полезно и интересно.
Re[2]: Разработка кроссплатформенной игры на web движках
Здравствуйте, glap, Вы писали:
G>Здравствуйте, C0x, Вы писали:
C0x>>Товарищи игроделы!
C0x>>Как вы рассматриваете перспективность разработки игры на браузерных движках?
C0x>>Речь идёт о том что изначально игру делать в браузере на каком нибудь babylon.js или three.js используя js или typescript. Для сети вебсокеты. А позднее когда игра готова оборачивать игру в electron или CEFSharp и издавать для десктопа в Стиме.
C0x>>Логика моя такая: 1) браузер (canvas, webgl) уже на высоком уровне поддерживаются браузерами + есть движки хорошего уровня. 2) запоковать для десктопа тоже не проблема хоть для мобильной хоть для любой десктопной платформы. 3) делится вебной версией проще простого, кинул ссылку и все.
G>Делал коммерческие игры не меньше чем на десятке технологий. Сейчас свой бизнес перевёл таки на Юнити.
G>Комментирую из прочитанного в ветке: G>1. Интерфейс верстать на ХТМЛ для игры не стоит. Это сильно сложнее чем мышкой в Юнити и выглядеть будет топорно. Игры это не совсем приложения.
Если нет опыта в веб-верстке то наверно, да, проще мышкой в юнити. если опыт есть то скорее всего проще в html,css нафигачить супер динамичный интерфейс несколькими строчками.
G>2. Игры это много специфического кода. Быстрой физики, например, на JS не может быть принципиально. Только в ВебАссембли если.
Незнаю что имеется ввиду под специфичным кодом, но логику игры (описание объектов и их поведения) без разницы на чем делать. Я например, давно, игры пописывал на чистом Си и мне нравилось. Более того находил это намного более простым чем вся эта ООПшная хрень в современных движках. Для физики и прочих плюшек есть куча библиотек на том же js, и врядли они уступают нативным аналогам. Я имею ввиду 2D физику.
G>3. Работа с графикой. В Юнити внятная система шейдеров со сборкой под любую платформу и прочее. Там реально большая работа проделана.
GLSL шейдеры поддерживаются сейчас всеми браузерами. Даже редакторы вот есть https://github.com/spite/ShaderEditorExtension
G>4. Поддержка конечных платформ это нудная рутина. Если можно заплатить 150 баксов в месяц и избавиться от этого на 95%, то так лучше и сделать.
Когда пишешь под браузер, то фактически поддерживать нужно только одну платформу. Ну с мобильным рынком свои ньюансы, но сильно зависит от типа игры. Если какой-нибудь 2д платформер, то и гемора для портирования под мобильный браузер скорее всего не будет. По аналогии с резиновыми сайтами.
G>5. Все JS движки не имеют хорошей расширяемой среды разработки. Приближается к этому только CocosCreator. Его я и использую если надо прям очень именно JS. Но на фоне Юнити он бледный конечно.
Среда разработки: Visual Studio Code + Notepad++, что еще надо?
G>В общем если надо именно игры делать, а не возиться с инструментарием, то выбора особо и нет. Но для опыта повозиться конечно полезно и интересно.
Все зависит. У меня нет денег на раскрутку, мне нужна хорошая конверсия. Самая лучшая конверсия это когда ты открыл ссылку и начал играть. Да Юнька может экспорт делать для WebGL, но как мне показалось качество страдает.
Могу ошибаться по каждому пункту, т.к. я не профи геймдев.
Re[3]: Разработка кроссплатформенной игры на web движках
Здравствуйте, C0x, Вы писали:
C0x>Если нет опыта в веб-верстке то наверно, да, проще мышкой в юнити. если опыт есть то скорее всего проще в html,css нафигачить супер динамичный интерфейс несколькими строчками.
Дискуссионный вопрос, но это ровно тот класс задач, что лучше решается визуально. Дизайнера можно привлечь непосредственно.
Ну и честно говоря слабо представляю как смешивается слой OpenGL с HTML. Интерфейс не всегда поверх объектов.
C0x>Незнаю что имеется ввиду под специфичным кодом, но логику игры (описание объектов и их поведения) без разницы на чем делать. Я например, давно, игры пописывал на чистом Си и мне нравилось. Более того находил это намного более простым чем вся эта ООПшная хрень в современных движках. Для физики и прочих плюшек есть куча библиотек на том же js, и врядли они уступают нативным аналогам. Я имею ввиду 2D физику.
Уступают по скорости. Это ограничивает количество объектов и, соответственно, вашу фантазию. На самом деле на JS даже динамический батчинг тормозит. Это умеренное количество работы с числами на ЦП для разгрузки ГПУ. В JS оно почти не окупается, а чаще вредит.
C0x>GLSL шейдеры поддерживаются сейчас всеми браузерами. Даже редакторы вот есть https://github.com/spite/ShaderEditorExtension
Но это низкий уровень языка и старый стандарт не раскрывающий потенциал видео-карточек даже на мобилах. Но если задача просто спрайты выводить, то разницы особо нет.
C0x>Когда пишешь под браузер, то фактически поддерживать нужно только одну платформу. Ну с мобильным рынком свои ньюансы, но сильно зависит от типа игры. Если какой-нибудь 2д платформер, то и гемора для портирования под мобильный браузер скорее всего не будет. По аналогии с резиновыми сайтами.
На мобилах если хотите в магазин приложений, то будет вызов системных методов и боль с рекламными сетями, статистикой и прочими библиотеками. Оно всё нужно если задача что-то заработать в том числе. А напрямую из браузера на мобилах не играют совсем. Надо JS таки оборачивать будет во что-то нативное и в магазин.
C0x>Среда разработки: Visual Studio Code + Notepad++, что еще надо?
К перечисленному набору у себя добавьте ещё сборщик атласов, сжатие текстур, конвертер звука, работа со шрифтами, редактор анимаций, скрипты сборки и что-нибудь я ещё забыл. Будет зоопарк утилит и скотч на коленке. В Unity и CocosCreator'е оно в одном месте. Работа с ресурсами перестаёт быть тяжким трудом и появляется возможность делегировать задачи специалистам в конкретных областях, а не в компьютерных науках.
C0x>Все зависит. У меня нет денег на раскрутку, мне нужна хорошая конверсия. Самая лучшая конверсия это когда ты открыл ссылку и начал играть. Да Юнька может экспорт делать для WebGL, но как мне показалось качество страдает.
Про качество не очень понятно о чём именно речь. Но вот скорость загрузки на самом деле хороший аргумент. И тут снова посоветую китайскую подделку под Юньку — CocosCreator. Багов полно, документация ужасная, но есть среда, компактный и открытый код движка. Ну и собирает уже под кучу платформ.
Re[4]: Разработка кроссплатформенной игры на web движках
Здравствуйте, glap, Вы писали:
G>Дискуссионный вопрос, но это ровно тот класс задач, что лучше решается визуально. Дизайнера можно привлечь непосредственно. G>Ну и честно говоря слабо представляю как смешивается слой OpenGL с HTML. Интерфейс не всегда поверх объектов.
OpenGL с HTML — нкаких проблем наверное уже 2-3 года как...
дизайнеров по адаптивную верстку под сразу все размеры — миллионы и они дешевые и попадются иногда очень крутые.
C0x>>Незнаю что имеется ввиду под специфичным кодом, но логику игры (описание объектов и их поведения) без разницы на чем делать. Я например, давно, игры пописывал на чистом Си и мне нравилось. Более того находил это намного более простым чем вся эта ООПшная хрень в современных движках. Для физики и прочих плюшек есть куча библиотек на том же js, и врядли они уступают нативным аналогам. Я имею ввиду 2D физику.
специфика програминга на js обработки чисел есть, но не так страшно и скорее всего не уступит C# в юнити и возможноиз из js использовать мощности GPU
G>Но это низкий уровень языка и старый стандарт не раскрывающий потенциал видео-карточек даже на мобилах.
имхо на мобилах зоопарк карточек и никто в здравом уме потенциал всех карточек не стремиться раскрывать — что мы наблюдаем на практике
— не все даже игры класса А это делают. А уж рядовым разработчикам это и вовсе не нужно.
G>На мобилах если хотите в магазин приложений, то будет вызов системных методов и боль с рекламными сетями, статистикой и прочими библиотеками.
рекламных сетей под браузеры в 10 раз больше, а под мобильны трафик в 100 раз
Я бы даже сказал самая вкусная и прибыльная реклама только под мобильный браузер
и какие могу быть проблем со статистикой под браузер ?!?!
>>А напрямую из браузера на мобилах не играют совсем.
играют — все казино, вся эротика в виде игр так идет, в сторы это не пропускают все равно
>>Надо JS таки оборачивать будет во что-то нативное и в магазин.
тут нет никаких проблем
G> конвертер звука,
а это что за чудо-юдо? браузер сразу все играет и показывает никаких конверторов не надо
G> Но вот скорость загрузки на самом деле хороший аргумент.
делаете прогрессивную загрузку и игра стартует для юзера за 0.01 сек — вроде как юнити так не умеет, а на js-html-css делается
и еще раз — мобильные игры под ВК это огромный рынок и там юнити пролетает. Там сдк только JS
Здравствуйте, paradoks, Вы писали:
P>OpenGL с HTML — нкаких проблем наверное уже 2-3 года как...
Интересно. Попробую изучить.
P>дизайнеров по адаптивную верстку под сразу все размеры — миллионы и они дешевые и попадются иногда очень крутые.
У игр же совсем всё своё. Нормальные дизайнеры для игр на вес золота и ничего они про HTML не знают. Я нанимаю людей к себе в т.ч. для этой работы.
P>специфика програминга на js обработки чисел есть, но не так страшно и скорее всего не уступит C# в юнити и возможноиз из js использовать мощности GPU
Я привёл конкретные примеры.
P>имхо на мобилах зоопарк карточек и никто в здравом уме потенциал всех карточек не стремиться раскрывать — что мы наблюдаем на практике P> — не все даже игры класса А это делают. А уж рядовым разработчикам это и вовсе не нужно.
Мне нужно. Ну и не то чтобы прям зоопарк. Вулкан, Метал и GLES.
P>рекламных сетей под браузеры в 10 раз больше, а под мобильны трафик в 100 раз P>Я бы даже сказал самая вкусная и прибыльная реклама только под мобильный браузер P>и какие могу быть проблем со статистикой под браузер ?!?!
Речь о нативных обёртках.
P> P>играют — все казино, вся эротика в виде игр так идет, в сторы это не пропускают все равно
Только вот зачем туда лезть?
P>тут нет никаких проблем
Кроме отсутствия поддержки со стороны платформ и поставщиков рекламы, сервисов для ЮА и прочего. Много лишней работы.
P>а это что за чудо-юдо? браузер сразу все играет и показывает никаких конверторов не надо
Ох.
P>делаете прогрессивную загрузку и игра стартует для юзера за 0.01 сек — вроде как юнити так не умеет, а на js-html-css делается
Умеет.
P>и еще раз — мобильные игры под ВК это огромный рынок и там юнити пролетает. Там сдк только JS
У вас своя специфика, понимаю.
Re[6]: Разработка кроссплатформенной игры на web движках
Здравствуйте, glap, Вы писали:
G>У вас своя специфика, понимаю.
Есть огромный рынок казуальных игр, который раньше занимали Flash игры. Пользователей сотни миллионов. Скажу больше, многие из этих игры, которые написаны на HTML 5 успешно вставляются в Сторы. Посмотрите на список игр от того же Miniclip в сторах. А изначально все эти игры расчитаны на браузеры. Да и сам издатель браузерный. Раньше был Flash, сейчас HTML5.
Re[2]: Разработка кроссплатформенной игры на web движках
P>запрет на работу js в фоне, — то есть у гугла и эпла ДЛЯ МОБИЛЬНЫХ игр на JS путь на тотальное урезание всех игровых фич
всё правильно делают.
да в общем-то фоновая работа и у нативных приложений весьма лимитирована, по понятным причинам.
Re[7]: Разработка кроссплатформенной игры на web движках
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, glap, Вы писали:
G>>У вас своя специфика, понимаю.
C0x>Есть огромный рынок казуальных игр, который раньше занимали Flash игры. Пользователей сотни миллионов. Скажу больше, многие из этих игры, которые написаны на HTML 5 успешно вставляются в Сторы. Посмотрите на список игр от того же Miniclip в сторах. А изначально все эти игры расчитаны на браузеры. Да и сам издатель браузерный. Раньше был Flash, сейчас HTML5.
Про это понимаю. Когда во Флэше были деньги я им активно занимался. В переходный период портировал свои флэшки под мобилы нарастив целую инфраструктуру под это дело. Они хоть и выглядели почти как копии тех флэшек, но под капотом там уже совсем другое. Т.е. портирование из ВЭБа оно часто переписывание всё же. Я таких примеров знаю много у других компаний. Это не исключает конечно и обёрток поверх хтмл.
Мы больше тут про удобство разработки наверное в контексте мультиплатформенности. Есть нюансы.
Взять конечно какой-нибудь быстрый Пикси.ЖС и запилить своё окружение оно может быть интересно и результат может быть очень хорошим. Под какой-то хобби проект под браузеры с напором на скорость работы и быструю загрузку я б так и сделал.
Но товарищ-то про слоты и прочую унылую полулегальную жуть.
jQuery — игра удалена и тд подобный бред от И-анализатора)
