Размер самой карты, в единицах, не имеет значения для исполнения вообще. Просто имейте в виду, что Unity (как и любой другой игровой движок) использует поплавки для геометрии, а когда значения поплавка становятся слишком высокими или слишком низкими, things can get funny.
Важно, чтобы объем данных, которые ваша логика, сеть и движок рендеринга должны перекачивать. Это разные вещи, даже логические/сетевые данные, а ограничения на них сильно зависят от архитектуры вашей игры.
Давайте поговорим о сети. В качестве ваших ограничений используются два параметра: пропускная способность и латентность. Полоса пропускания - это то, сколько данных вы можете перенести, и как быстро. Хорошо, это объяснение сбивает с толку. Представьте себе грузовик, полный жестких дисков, путешествующих из одного города в другой: он имеет гигантскую пропускную способность, и таким образом вы можете передать целые центры обработки данных. Но латентность, время прохождения сигнала, составляет несколько часов. С другой стороны, два разных человека из этих городов могут прыгать на воздушных шарах, смотреть друг на друга в ночном небе и включать и выключать свои фонарики. Таким образом, они смогут обмениваться только одним битом информации, но с минимально возможной задержкой: вы не можете получить быстрее света.
Это также зависит от того, как работает ваша сеть. Например, игры RTS часто используют многопользовательскую архитектуру с блокировкой, которая может работать на тысячах единиц, но будет только обменивать ограниченный объем данных между пользователями: их команды ввода. С другой стороны, шутер от первого лица сильно зависит от латентности (который может блокировать блокировку): 10 мс, когда вы прыгаете и запускаете ракетный пусковой механизм, гораздо важнее, чем когда вы говорите, что ваши войска атакуют. Таким образом, сетевая логика организована по-разному: компьютер каждого игрока предсказывает, что произойдет, но центральный сервер имеет полномочия на то, что на самом деле произошло. Конечно, то, что я пишу прямо сейчас, - это просто общие примеры архитектур, которые можно использовать; выбор правильного пути для создания сетей - очень сложная, но очень интересная и творческая задача.
Теперь, сама логика. На самом деле, большая часть логики геймплея, используемая в современных играх, относительно проста с точки зрения требований к процессору, если только это не физика или ИИ. Использование физики в многопользовательской игре достаточно сложно для нее, из-за проблем с синхронизацией (помните, плавает?); обычно реальная логика, которая может влиять на тех, кто побеждает и кто проигрывает, довольно упрощена: геометрия уровня полностью статична, символы перемещаются с использованием простой логики без реальной физической силы, а физика обычно ограничена только обнаружением столкновения. Конечно, вы видите много визуальных вещей на физическом уровне: рагдоллы убитых врагов падают, обломки взрыва взлетают; но они обычно десинхронизируются между разными компьютерами и не могут фактически влиять на сам игровой процесс.
И, наконец, рендеринг. Здесь существует множество различных ограничений. Чтобы рассказать о них все, мне пришлось бы описать весь конвейер Unity на разных устройствах, и это явно выходит за рамки этого вопроса. К счастью, есть другой путь! Вместо того, чтобы рассуждать об этом пределе теоретически, просто к практическому прототипу. Поместите в разные игровые ресурсы в сцену, запустите ее на целевом устройстве и посмотрите, как она работает. Отрегулируйте, повторите! Эти игровые активы могут быть абсолютно уродливыми или неактуальными; однако они должны обладать такими же техническими свойствами, как то, что вы собираетесь использовать в реальной игре: количество полигонов, размеры текстур, шейдеров и т. д. и т. д. Скажем, например, что вы хотите создать ХПК подобный многопользовательский шутер. Чтобы придумать ваши требования к рендерингу, просто поместите N моделей среды с N многоугольями каждый, используя текстуры NxN, поместите N символов с некоторыми анимациями скелета с N костями, а также не забудьте какую-то фальшивую логику, которая будет эмулировать CPU-intenstive так что ваше измерение производительности будет более реалистичным. Конечно, это не даст вам окончательную картину, но это будет хороший способ начать, и это здорово сделать это, прежде чем вы начнете создавать множество арт-активов.
В целом оптимизация производительности игры - очень широкая и интересная тема, и невозможно точно ответить на такой вопрос.
Масштаб карт зависит, прежде всего, от масштаба модели. – Laykker
UnityScript очень далек от Javascript, и использование имени одного вместо другого может создать путаницу, поэтому я удалил тег. –
Верхняя граница по размеру карты в основном определяется ошибками точности с плавающей запятой. Там нет твердого номера, но вы будете получать все больше ошибок при удалении от источника. Unity иногда начинает отображать предупреждения примерно на 100 000 единиц (0,0,0). – rutter