12 часа назад, Nezgibaem сказал:
А что ты будешь делать когда склад заполниться, а тебе нужно будет сделать решип или просто купить новый корабль?
Ну и покупай. кто мешает. Просто если ты приобретешь на склад модуль или пушку для него, то склад уменьшиться на этот итем, а при установке в корабль, увеличится…
12 часа назад, Nezgibaem сказал:
Создашь динамический массив? Растягивающийся склад? И игра у тебя тут же вылетит в ошибку на конфликте адресов. Или ты реально получишь растягивающийся склад, как у нас сейчас с ресурсами, иридиумом(у некоторых) и тебе придётся всё равно что-то продавать, т.е. проблемы ты не решишь вообще никак. получив однотипный результат при иных условиях.
При чем тут эти все буковы… Массив получается в результате SQL запроса… И при чем тут адреса, это же тебе не ассемблер, Массив занимает столько места, сколько в нем записей, сейчас это 2500 элементов, То что я говорю, значительно уменьшит его размер, но точно не увеличит. И я не понял, тут одну штуку в твоих словах, если ты говоришь про то что на складе есть итемы, которых у тебя больше, чем положено по правилам, то это все го лишь вопрос кода, и никак не влияет на записи в БД.
И я не говорил, что это панацея, это простая заплатка, которая не несет никаких сложностей в самом коде и в БД. Разница в 2500 записях с полем 0/1 никак не отразиться на изменении до 5000 с тем же полем, ни по объему хранения ни по быстроте выполнения запросов.
12 часа назад, Nezgibaem сказал:
Это во первых, а во вторых. а куда ты денешь эти модули потом? Они по прежнему являются объектом, по прежнему занимают адресное пространство в массиве, так куда же ты его денешь? Удалишь из памяти? Тогда ты удалишь его совсем, он исчезнет, слот будет считаться пустым. Переместишь? Т.е. вместо команды обращения к свойству объекта, ты предлагаешь создать отдельный объект?
Ну опять много буков от человека, который имеет опыт в работе исключительно с NoSQL БД и все держит в каком то гребаном безразмерном массиве и обращается к его веткам как к не свзянным документам. Массив, это временный объект, для оперативной необходимости. Его можно создать в любой момент, объявить его, заполнить, переформатировать, пересортировать, исключить элементы и в конце концов удить - прямо в коде исполнения.(ну тут есть варианты для разных языков, некоторые требуют объявлять массивы заранее для выделения памяти).
И отвечая на твой вопрос, то если мы поставим в условиях не выводить на складе, те модули и пушки (и боеприпасы и ракеты), которые установлены в корабли, то сам массив будет меньше для обработки, Но тут не во всяких решениях, NoSQL база выдает в результате все, а потом кодом выбираются нужные элементы, так делает та же монга (ужасная БД), ресурсоемкая и медленная и все держит в памяти… Кошмар…
12 часа назад, Nezgibaem сказал:
Мы получим “современную” игру, и я не ошибся с термином, сейчас все прочие разработчики идут именно по пути “натурализации” объектов, поэтому сейчас все игрушки такие неподъёмные, многогигабайтные и постоянно лагающие, потому что вместо обычных ссылочных обращений они вынуждены затрачивать море ресурсов для перенесения или пересоздавания объектов.
Это в Вас говорит человек не привыкший эффективно использовать память и оставить на саму ОСь вопрос ее освобождения по таймауту. Нормальная современная разработка, как раз работает с динамическими данными (в том числе и массивами) и разработчики "прибирают за собой локальные части данных после использования, конечно если это не глобальная переменная с глобальной областью видимости.
Много индусов, которые пишут современные игрухи, научились их писать быстро и оставлять все в памяти. ну это вызвано тем, что у них разработка настолько поделена на сегменты, что никто по сути дела не знает, когда какой объект будет востребован в процессе исполнения кода. В связи с этим они научились обзывать переменные и процедуры нативными названиями, что бы другие команды, не путались и смогли воспользоваться уже существующим… Но все равно в 50% случаях одна команда разрабатывает функцию, которую уже реализовала другая команда… Вот тебе и размер, как кода так и места в памяти… И все это одновременно живет…
Компилят сборку и отдают тестерам, те проверяют, если нет глюков то в продакшинс, потому что тестеры сегодня не разбираются и не проверяют содержания кода и просто забивают на 20 одинаковых функций с разными названиями…
ПС. В общем проблема размера Это не проблема кода или подхода, это проблема организации написания софта… Знаю, по себе - когда я настоял на том, что в нашем решении надо навести порядок и мы выкинули все дубли и согласовали использование глобальных переменных, то уменьшили сам код процентов на 40% и требования к памяти на 20%… Не слабо так…
ППС. Давай перестанем спорить, я высказал свое мнение, если разрабы читают тред, то вероятно они услышали и может что то сделают, предварительно проанализировав влияние этого изменения. Если же это может привести к сложностям, то вероятно это не реализуется (а они могут возникнуть, если в игре существует один единственный массив, созданный по технологии (key- value))…