>>44725> Прикрепил пик.
Во, отлично.
Теперь тут надо дальше рассматривать варианты вертикального строительства. Продолжи схему с достраиванием следующего здания. Отдельно так и отдельно вариант другого размера, большего по площади скажем раза в два.
> Объясни. Как еще ты представляешь строительство?
Я гляжу ты вообще не представляешь как такие вещи делаются в играх.
В пределе возьмём четыре ситуации квантования пространства - тайловую, эту самую кубическую, "2д-векторную" и "3д-векторную":
• При тайлах (вариант большинства градостроев - SC1-SC4, Тропико1-2, Анно, тд тп) даже при наличии высоты у ландшафта, логически мы имеем лишь 2D сетку. В каждом тайле может находиться лишь один обьект, хотя сам обьект может занимать несколько тайлов. Это хорошо заметно в SC4 при строительстве дорог. К диагональной дороге нельзя диагонально пристроить здания и в тайле с диагональной дорогой уже невозможно построить что-то ещё, так как длинна диагонали приблизительно на 1/3 длиннее ширины и высоты. При этом число там фактически иррациональное, поэтому для унификации контента в чистую добиться кратного соотношения между диагональю и стороной тайла - невозможно. То есть любой обьект должен быть кратен длинне и ширине тайла. Любые мелкие обьекты, как например всякие машинки в SC4, могут исключительно находиться в локальной системе координат обьекта в пределах тайла. Если скажем надо сделать так что бы один суб-обьект мог продолжаться на другом обьекте, тут тут опять те же самые задачи - либо кратное квантование, либо малое конечное число заготовленных вариантов, либо переход к иному квантованию аля вектора.
• При униформных ААББ кубах мы получаем аналогичную, но 3D сетку. Тут всё тоже самое, только кратность любого обьекта равна стороне куба. То есть обьект никак не может быть сдвинут менее чем на длину стороны и повёрнут менее чем на 90 градусов.
• Векторное 2д - это в духе последних тропико, сим сити, ситис ХЛ и другие. Суть в том, что явного квантования там нет, а используется набор гвайдлайнов аля фотошоп. То есть каждый обьект имеет свои правила привязки к другим игровым обьектам. Например здания автоматом магнитятся к дорогам, а новые дороги магнитятся к узлам привязки зданий, тд тп. В этом варианте кратности может не быть вообще, но как правило она есть, скажем как в ситиз хл. Почему? Потому что игрок размечает не здания, а зоны, которые заполняются произвольными униформными обьектами. В теории можно и зонирование сделать не униформным используя например алгоритмы для упаковки спрайтщитов.
В отличии от кубов тут возникает огромное количество технических задач. Если при тайлах всё что нам надо это два флора, то в векторном пространстве надо организовывать достаточно замудрённую систему ориентирования основанную на 3д геометрии - это как тригонометрия, только ещё в 3д и с десятком нетривиальных задачь. Так же векторное расположение как правило требует не просто расположить обьект, но и деформировать его определённым образом, как например дороги, трубы, ЛВП и тд. К тому же это всё может сходиться абсолютно под разными углами и в произвольном месте. А значит тут уже встают задачи процедурной генерации. А процедурная генерации как правило обходиться очень дорого. То есть фактически организация и сложность между тайлами и вектором отличается на порядки, если не на несколько, как в плане кода так и в плане контента.
Поэтому естественно в чистую процедурную игру никто не делает и делает некий гибрид достаточный для поставленных геймплейных задач. Собственно ко всему этому сейчас вся моя работа и сводится - что и как можно делать процедурно и что и как делать униформно. В этом смысле я уже читал всякие СНИПы и тд.
• Векторное 3д - всё тоже самое, только с дополнительной вертикальной логикой. И тут надо понимать, что если например игра 3д и использует 3д ланшафт с высотой, но строить надо чётко по 2д сетке, то это по механике 2д игра. Но если в игре можно над зданием поместить дорогу и механика не ограничивает от того, что бы над этой дорогой построить ещё одну
как например в Локомоушен, то это уже 3д механика. То есть высота должна быть не просто параметром при расчёте скорости перемещения авто или вычисления возможности строительства, а действительно дополнительным уровнем, логика которого полноценно зависит от третей оси.
На уровне представления данных конечно тут совсем всё иначе. Механике по сути пофиг вообще на любую человеческую логику - тут она своя. Тайлы в пределе могут быть просто 1д или 2д массивом. При этом не имеет особого значения 3д или 2д игра, вид сверху, изометрия или косоугольная изометрия - это всё контент и представление данных. В векторном простренстве - это точки, вектора, кривые, ААББ и произвольные шейпы. На террейне они должны быть дополнительно спроецированны на ландшафт, если он имеет высоту. Всё это разбито и разложено в какое нибудь дерево - квад или окто. Соответственно хорошо бы что бы все обьекты были пронумерованы и проиндексированных в специальных хэшь-таблицах для быстрого поиска. А это всё требует грамотного сплетения ООП с АОП.
• Помимо этого есть ещё всякие воксели, но они как правило используются только для представления.
Надеюсь в этом бриф луке я доходчиво обьяснил, почему весь мир не состоит из кубов и что это занимательное наблюдение не имеет абсолютно ничего с реалиями разработки.
> Странно, что ты вообще тогда что-то у кого-то спрашиваешь и не понимаешь элементарных вещей.
ruwiki://Эффект_Даннинга_—_Крюгера Когда я разговариваю с людьми кто так же как и я по-настоящему работает над играми, проблемы взаимопонимания возникают крайне редко. И я как-то видать сильно к этому привык, что такое приводит меня в некоторое раздражение.
> Заранее планировать и четко проектировать это не "накидайте мне вариантов". Тк тех вариантов, что ты просишь может быть сотня и более.
Ок. Разработка игры состоит из 5 этапов:
1. Идея.
2. Пре-продакшен.
3. Продакшен.
4. Пост-продакшен.
5. Афтер-маркет.
1. Идея - на этом этапе выбирают идею и проводят предварительное исследование, что бы понимать что идея вообще выполнима. Выбор технологии + маркетинг + арт.
1.1. Фокус - основная фича игры.
1.2. УСП - уникальные продающие фичи.
1.3. Рефы - материал который помогает создать вижен игры.
1.4. Вижен - образ игры.
1.5. Концепт-док.
1.6. Прототипы технологий и гп.
1.7. Поиск единомышленников.
2. Пре-продакшен - планирование, проектирование и создание прототипа.
2.1. Полноценное исследование - определить конкретно что, как, кто, на чём, за сколько и как дорого.
2.2. Сеттинг, сценарий, концепт персонажей, концепт уровней, тд тп.
2.3. Сбор команды и лицензий.
2.4. Дизайн-док - достаточное описание и план продакшена - пайплайн.
2.6. Альфа.
3. Продакшен - согласно плану и пайплайну - сесть и сделать.
3.1. Контент.
3.2. Бэта.
4. Пост-продакшен - тестирование и полировка.
4.1. Дебаг.
4.2. Баланс.
4.3. Локализации, тд тп.
4.4. Демо и Мастер.
5. Афтер-маркет.
5.1. Саппорт, тд тп.
У нас идёт этап идеи, а значит всё по плану. Можешь дать сотню идей - давай, никаких проблем.
> "Мысью по древу" не грех и растечься, особенно если от этого многое зависит.
Если тебя спрашивают, а ты отвечаешь невпопад и тебя не понимают - это лишь трата времени.
> И расскажи мне про отсутствие кубичности в антропоморфном. Или ты готов делать свой город фракталами?
Смотри выше. А фракталы - это лишь частный случай процедурной генерации, обычно используют гибридные и модифицированные техники для генерации ландшафтов. Генерация зданий фракталами не делается.
> Не нужно изображать глупца. Это логика.
Ну а логика - это лишь метод формального анализа. Я же спрашиваю тебя по существу.
Если тебя просят обьяснить и доказать какое либо твоё высказывание - это значит, что с "твоей логикой" не согласны.
> Я рассказывала выше как строится город. Говорил вокруг чего возникает город.
> Пусть на первый взгляд и кажется, что город можно строить свободно и хаотично, но это ошибочно. Город это единый организм. Даже самые необычные типы городской планировки заранее продуманы.
И что ты предлагаешь? Не давать игроку строить город ни как иначе, чем это будет заложено в коде? И при этом как это всё закладывать? if (building.isCloseToRoad()) building.population++? С точки зрения механики абсолютно бесполезны заявления аля "около дорог будут расти жилые кварталы", в проектировании собственно важно само доказательство, а не факт. При этом в идеале надо, что бы логика действительно была настоящая, обоснованная, по существу, а не притянутая за уши, дабы "подвести под научную базу".
В этом плане надо идти от проблем - то есть думать почему то или иное строение выглядит так как выглядит и располагается там где располагается.
То есть, что я хочу сказать - всё что связано с планированием города, хаотичность или продуманность - этим занимается исключительно игрок. Захотел сделать хаотичность - пжлст. Захотел продумать или всё сделать кубами - не менее. Никаких предзаданных планировок или механизмов заставляющих следовать исключительно им.
> Я прошу тебя понизить планку высокомерия и начать прислушиваться к моим словам наравне и с моей попыткой понять тебя, если ты хочешь продолжать это со мной.
Я хз что такое высокомерие. Мне главное проект. Кто мешает - вон. Кто помогает - добро пожаловать. Просто не привычно работать с новичками, но буду стараться, и надеюсь в этот раз всё обстоятельно обьяснил.
Ух.. сто лет этот пост писал
:/
