Еще раз повторюсь — выбирайте инструмент в зависимости от проекта. Сравнение в одной из плоскостей с Unity это лишь небольшой, и совершенно не главный кусочек доклада ;)
Ну вот вы ярко расписываете, что игра прекрасно работает на iPhone 5s, да ещё и намекаете, что завтра он войдет в историю, и уже iPhone 6\6s будет минимальным целевым устройством. Android вы решили благополучно опустить, правда не понятно почему.
Я даже не намекаю, я это весьма уверенно утверждаю :) На текущий момент, разрабатывая игру для iOS, девайс iPhone 6 можно смело считать минимальным. И да, эппл как был, так и остаётся самой денежной мобильной платформой, в то время как Android — обладает большей пользовательской массой. Если вы целитесь в лоу-энд девайсы андроида — это тоже свой рынок, но лишь его часть -есть и другая, весьма многочисленная, часть андроид устройств с прекрасной производительностью.
Вы оперируете тем, что если речь идет о гигабайтных ассетах, то это не важно.
Мой основной поинт — в хорошую игру будут играть не смотря на размер, а для стран, где проблемы со сторами аля китай, легко выпускается версия, где докачка контента происходит уже в самой игре. А плохую игру или треш — сейчас уже просто так «из-за размера» качать никто не будет. Да, «меньший размер» — это плюс, но далеко не в первых рядах. И речь ведь не только о «гигабайтных ассетах» — игра 300-400 метров это уже не 150, но и далеко не гигабайты.
Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3.
Супер, я очень рад если ребята из Юнити наконец сделали это на должном уровне, но вообще поинт был совсем не об этом. На ранних версиях UE4 с длиной итерации под мобилки были сильные проблемы. Потом — они ушли. Вжух, счастье, радость :)
Тем не менее, если вы серьезная компания и разрабатываете гигабайтные игры, вам не составит труда обговорить этот вопрос с Unity, договориться обо всем и получить свои долгожданные исходники, чтобы переписать все, что вам необходимо, будь то освещение, физический движок или любые другие вещи.
А на самом деле — нет, это весьма «составит труда», и вообще одна из главных печалей тех, кто делает серьезные проекты на юнити. Прям такая, что немало слёз разработчиков об этом пролито.
Все имеет значение. 45 Мб это 9 несжатых фонов в FullHD. Мб можно этот параметр как-нибудь улучшить?
Можно, но в ущерб тем или иным вещам. Лично я не вижу в этом никакого смысла совершенно — лучше потратить время и силы на совсем другие вещи :) «Маленькие игры» — это отдельный бизнес.
Так что больше потребляет на среднем билде в средней игровой ситуации?
К сожалению понятия «средний» для такой ситуации нет — все слишком зависит от конкретной игры.
Я сам весьма настороженно отношусь к холиварам, но приветствую «pros vs cons» сравнение технологий, в первую очередь со стороны бизнеса. Выбор технологии отдельным разработчиком, и выбор компанией/студией — несколько разные вещи.
Неплохая статья в целом, но есть некоторая мешанина советов борьбы с читерами, косяков архитектур и очень частных случаев, возникших из-за этих самых косяков.
НЕЛЬЗЯ придерживаться deterministic-lockstep архитектур (в которых синхронизация происходит только отправкой данных ввода).
Если игра — это RTS (или просто имеет положим >100 одновременно релевантных юнитов), то нельзя НЕ придерживаться такой архитектуры. А вот использование локстепа в иных случаях — это да, вызывает вопросы.
Было бы очень здорово, если бы вы ещё написали чем технически отличаются касты к интерфейсу и к классу, какие "последствия" несёт за собой каждый случай, и почему использование интерфейсов в целом более предпочтительно для интерфейса и базовых классов, а в рамках экторов на сцене — в общем случае каст будет быстрее и проще ;)
Потому что эти два механизма существуют не просто так и их нельзя назвать эквивалентными.
Мне сложно представить ситуацию, при которой потребовалось бы кидаться с сервака таким типом данных, но даже если так — из TAssetPtr прекрасно достается FStringAssetReference, который можно отправить RPC'шкой на клиент в нужный момент :)
А что с ним не так? Он же не более чем шаблонизированная обвязка над FStringAssetReference, что позволяет не мудрствуя лукаво отсекать ассеты по классу, вместо опасной возможности «вставить всё куда угодно».
По урокам не подскажу, т.к. сам использовал всегда только документацию. Но если вы конкретизируете что вас интересует, может подскажу предметно (или может послужить материалом для следующей статьи :) )
Еще раз повторюсь — выбирайте инструмент в зависимости от проекта. Сравнение в одной из плоскостей с Unity это лишь небольшой, и совершенно не главный кусочек доклада ;)
Я даже не намекаю, я это весьма уверенно утверждаю :) На текущий момент, разрабатывая игру для iOS, девайс iPhone 6 можно смело считать минимальным. И да, эппл как был, так и остаётся самой денежной мобильной платформой, в то время как Android — обладает большей пользовательской массой. Если вы целитесь в лоу-энд девайсы андроида — это тоже свой рынок, но лишь его часть -есть и другая, весьма многочисленная, часть андроид устройств с прекрасной производительностью.
Мой основной поинт — в хорошую игру будут играть не смотря на размер, а для стран, где проблемы со сторами аля китай, легко выпускается версия, где докачка контента происходит уже в самой игре. А плохую игру или треш — сейчас уже просто так «из-за размера» качать никто не будет. Да, «меньший размер» — это плюс, но далеко не в первых рядах. И речь ведь не только о «гигабайтных ассетах» — игра 300-400 метров это уже не 150, но и далеко не гигабайты.
Супер, я очень рад если ребята из Юнити наконец сделали это на должном уровне, но вообще поинт был совсем не об этом. На ранних версиях UE4 с длиной итерации под мобилки были сильные проблемы. Потом — они ушли. Вжух, счастье, радость :)
А на самом деле — нет, это весьма «составит труда», и вообще одна из главных печалей тех, кто делает серьезные проекты на юнити. Прям такая, что немало слёз разработчиков об этом пролито.
Можно, но в ущерб тем или иным вещам. Лично я не вижу в этом никакого смысла совершенно — лучше потратить время и силы на совсем другие вещи :) «Маленькие игры» — это отдельный бизнес.
К сожалению понятия «средний» для такой ситуации нет — все слишком зависит от конкретной игры.
Неплохая статья в целом, но есть некоторая мешанина советов борьбы с читерами, косяков архитектур и очень частных случаев, возникших из-за этих самых косяков.
Если игра — это RTS (или просто имеет положим >100 одновременно релевантных юнитов), то нельзя НЕ придерживаться такой архитектуры. А вот использование локстепа в иных случаях — это да, вызывает вопросы.
Было бы очень здорово, если бы вы ещё написали чем технически отличаются касты к интерфейсу и к классу, какие "последствия" несёт за собой каждый случай, и почему использование интерфейсов в целом более предпочтительно для интерфейса и базовых классов, а в рамках экторов на сцене — в общем случае каст будет быстрее и проще ;)
Потому что эти два механизма существуют не просто так и их нельзя назвать эквивалентными.