Search
Write a publication
Pull to refresh

Comments 4

Да, это было сильно.

Тут давеча барышня про запятые пост выкладывала. Почитайте, когда отдохнете от "квантовых состояний". Вы запятые от балды лепите, похоже.

Собственно, слова вы тоже не особо выбираете. Берете получше, сочнее. Статистика с внутренними состояниями (она же модульность) и завихрения в кольцах Сатурна мне понравились.

И я пытался "игру слов" найти. Не нашел. Плохо. Слова нашел, в игру нет

Спасибо за подсказки! Буду тренироваться бОльшей граматности!

Описанное в статье подходит для игры с дискретной тайловой картой, целиком влезающей в экран. Тут действительно никаких переборов не нужно, хотя решение все равно странное на нескольких уровнях. В оригинальной же статье координаты игроков заданы парой вещественных чисел, а поле можно увеличить во сколько угодно раз.

Даже если мы остановимся на тайловости. Банальный пример. Размер карты 5000х5000, мультиплеер, 1000 игроков, каждому из которых в монитор влазит 50х50 тайлов.

При использовании приведенного решения карта будет впустую занимать непомерный объем оперативной памяти. Что можно даже частично исправить, если отказаться от чистого parallel arrays, и хранить в тайлах только id, а данные игроков отдельном массиве структур. Но это будет все еще слишком много. О том как это отправлять и обновлять одновременно тысяче игроков даже подумать страшно.

А теперь представим, что у игроков появилась функция "телепортироваться к другу". У нас не останется выбора кроме как хранить их координаты в структуре игрока. В итоге все сведется к классическому подходу, но с использованием чрезмерно детализированной uniform grid как средства оптимизации некоторых операций.

Согласен. И при чем тут квантовые состояния? Где "внутренняя динамика внешне статического объекта"? Зачем было вообще это невнятное вступление?

Про проектируемый язык программирования даже думать боюсь.

Sign up to leave a comment.

Articles