Моя контора "сменила вектор развития". Теперь делаем веб. Пришлось пересесть с юньки на cc, так как свой tiny они забросили.
Жить с двиглом можно, но есть много нюансов.
Он пытается быть похожим на юньку подходом, и даже названиями методов, но, при этом, даже из базовых вещей реализовано далеко не все, а где-то нейминг пришёл из старых версий вообще. В итоге юнитевый багаж может сыграть злую шутку. Например, в юнити есть position и localPosition. А в кокосе они worldPosition и position соответственно. Система координат другая.
Надо ли говорить сколько проблем возникало из-за "привычки"? А сколько багов возникало по-началу при портировании из-за этой, кажущейся, "такой же"-сти?
Возможно, самый неприятный момент это векторная математика. Жс в перегрузку операторов не умеет, поэтому там где в юньке мы просто пишем vector1+vector2*vector3 в кокосе превращается во что-то,вроде, vector1.add(vector2.mul(vector3)). А когда действий много то вместо одной строчки приходится на целый абзац это дела расписывать, чтобы оно было читаемо. Так же, набор тулзов здесь сильно меньше чем в юньке, всякие конвертеры из спейса объекта в мир иногда приходится самостоятельно писать.
Второй неприятный момент это сам веб. Загрузка любого ресурса асинхронна, поэтому там, где в юньке мы могли когда надо загрузить префаб и сразу же с ним что-то сделать, в cc придётся сначала дождаться его загрузки, при этом, естественно, движок продолжит работу. Поэтому, если один компонент должен породить объект, а другой в том же кадре с ним что-то сделать то приходится что-то костылить. Это, во многом, вопрос архитектуры, но когда ты привык к юньке. И, тем более, когда ты портируешь существующую логику...
Что касается 3д - в него вполне можно, но есть проблемки. Освещение в игре реализовано дёшево, но коряво. По умолчанию вообще тени рендерятся проекторами. Шедойумапы дорогие. Система материалов местных это тихий ужас (опять же, по сравнению с юнити). Жить с ними можно, набор шейдеров комплектных для небольших игр сойдёт, pbr есть. Писать свои материалы в cc страшно. Документации нет, всё как-то через задницу. Это вам не shaderlab. Хотя, уверен, есть движки где дело обстоит и хуже. В остальном для 3д всё есть - физика, анимация, пятиклассник(даже физичные).
Ну и вишенка это сам веб. Необходимо понимать как работает браузер, веб запросы, что такое CORS, как typescript компилится в js и как это дело отлаживать. Иногда компилятор творит дичь и оптимизирует то, что оптимизировать ни в коем случае было нельзя.
По поводу сборки под стим - вроде ниче сложного там нет, предлагается просто использовать electron. С ним один раз разобраться, потратив час-два времени, а потом просто обновлять файлики в проекте.
Статья выглядит как попытка заявить о своём проекте используя КРАЙНЕ надуманную проблему. Но всё-равно успехов.
Аппаратная эмуляция, обычно, с точки зрения логики вовсе и не эмуляция)
Моя контора "сменила вектор развития". Теперь делаем веб. Пришлось пересесть с юньки на cc, так как свой tiny они забросили.
Жить с двиглом можно, но есть много нюансов.
Он пытается быть похожим на юньку подходом, и даже названиями методов, но, при этом, даже из базовых вещей реализовано далеко не все, а где-то нейминг пришёл из старых версий вообще. В итоге юнитевый багаж может сыграть злую шутку. Например, в юнити есть position и localPosition. А в кокосе они worldPosition и position соответственно. Система координат другая.
Надо ли говорить сколько проблем возникало из-за "привычки"? А сколько багов возникало по-началу при портировании из-за этой, кажущейся, "такой же"-сти?
Возможно, самый неприятный момент это векторная математика. Жс в перегрузку операторов не умеет, поэтому там где в юньке мы просто пишем vector1+vector2*vector3 в кокосе превращается во что-то,вроде, vector1.add(vector2.mul(vector3)). А когда действий много то вместо одной строчки приходится на целый абзац это дела расписывать, чтобы оно было читаемо. Так же, набор тулзов здесь сильно меньше чем в юньке, всякие конвертеры из спейса объекта в мир иногда приходится самостоятельно писать.
Второй неприятный момент это сам веб. Загрузка любого ресурса асинхронна, поэтому там, где в юньке мы могли когда надо загрузить префаб и сразу же с ним что-то сделать, в cc придётся сначала дождаться его загрузки, при этом, естественно, движок продолжит работу. Поэтому, если один компонент должен породить объект, а другой в том же кадре с ним что-то сделать то приходится что-то костылить. Это, во многом, вопрос архитектуры, но когда ты привык к юньке. И, тем более, когда ты портируешь существующую логику...
Что касается 3д - в него вполне можно, но есть проблемки. Освещение в игре реализовано дёшево, но коряво. По умолчанию вообще тени рендерятся проекторами. Шедойумапы дорогие. Система материалов местных это тихий ужас (опять же, по сравнению с юнити). Жить с ними можно, набор шейдеров комплектных для небольших игр сойдёт, pbr есть. Писать свои материалы в cc страшно. Документации нет, всё как-то через задницу. Это вам не shaderlab. Хотя, уверен, есть движки где дело обстоит и хуже. В остальном для 3д всё есть - физика, анимация, пятиклассник(даже физичные).
Ну и вишенка это сам веб. Необходимо понимать как работает браузер, веб запросы, что такое CORS, как typescript компилится в js и как это дело отлаживать. Иногда компилятор творит дичь и оптимизирует то, что оптимизировать ни в коем случае было нельзя.
По поводу сборки под стим - вроде ниче сложного там нет, предлагается просто использовать electron. С ним один раз разобраться, потратив час-два времени, а потом просто обновлять файлики в проекте.