prog:

Ну когда я о нём узнал, я только вкатывался в область, и для меня такое эффективное упрощение было почти откровением, оттуда и такие нотки в статье. Ну и потом, когда с тобой делятся даже базовой информацией в формате «откровения», невольно больше ею проникаешься, педагогический эффект сильнее, на это тоже ставку делал.

Независимо от наполнения, игра (компьютерная) всегда есть модель, вполне логично, что чтобы делать красивые модели, надо знать, как их делать и как они работают. В общем, полностью согласен.
Мне, можно сказать, повезло: был в жизни длительный период меланхолии, и я просто запоем читал статьи (часто из той же википедии) и исследования по всем направлениям, до которых мог дотянуться, просто чтобы отвлечься. И математику, и физику, и социологию с биологией, в общем, чем абстрактнее было, тем лучше; очень увлекательно было читать различные исследования и теории о явлении сознания. Плюс ещё в какой-то момент увязать всю эту информацию в единую цельную модель помогла кислота, чего уж тут таить.

Беда современных разработчиков игр в том, что они совсем не читают классику - теорию игр ту же, например, это которая вовсе не о компьютерных играх, а о логике и математике. Азы психологии тоже не помешали бы. Упомянутое в статье "правило шести" тоже видел в азах какой-то из областей, уже не соображу в какой именно, именно в основах, с которыми знакомится человек впервые решивший что-то узнать на тему, а не на правах какого-то откровения.

NazarPunk:

Пять рядов - да, пять яблок - да, однако для пяти рядов по пять яблок придётся чуть-чуть, но задуматься, ответ не будет интуитивным.

Целью статьи является попытка вынести на поверхность не различия, а, напротив, универсальные абстрактные сущности.

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

Цель - понять, когда отвечающему приходится пересчитывать предметы для ответа, а когда он отвечает не задумываясь.

Пять рядов по пять яблок можно ответить не пересчитывая.

подавать игроку один и тот же геймплей

тут уже всё размыто донельзя. Если гэймплэй это способ взаимодействия игрой, то я бы выделил:

• рефлексы и быструю реакцию как в шутерах, слэшерах
• сюжет как в RPG
• пошаговые игры как шахматы или герои

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

Масло маслиное. Давай исчо.

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

Не стоит воспринимать всё написанное как относящееся исключительно к играм, почти всё может быть применено и ко многим другим аспектам жизнедеятельности =)

Ну и конечно вопросы, пожелания и советы по написанию приветствуются.

vasex, скорее всего потому что v1 == v2
либо гдето перемудрил с присваиваниями либо right_hand_item() и on_head_item() возвращают один и тотже объект

хм, помогла замена все этих объектов-классов на простые переменные (которые я объявил везде глобалами):

xx = all_item_names[i][0]
xxx = all_item_names[i][1]
или
zz = all_item_names[i][0]
zzz = all_item_names[i][1]

Теперь код работает, как надо. в руке (хх) - палка, в голове (zz) - шлем, как не ворочай, всё получается.

Только я, наверное, всё равно слишком тупой, чтобы понять, почему не работает это:

1. один объект присваивает значение словаря при одном условии...
2. совершенно другой объект, никак не связанный с предыдущим (кроме слова name и одного и того же словаря, но с разными i в зависимости от условий), присваивает совершенно другое значение словаря при совершенно другом условии...
3. но почему-то в итоге в обоих объектах в итоге записано одно и то же свежее значение из словаря... и проблема, как теперь известно, не в i, которое корректно в зависимости от условий меняет значение словаря...

name ведь не общее у двух разных объектов двух разных классов, а как бы характеризует своё уникальное значение, ну как у одного героя имя одно, а у другого имя другое, я даже классы их разделил (right_hand_item_1 = right_hand_item() и on_head_item_1 = on_head_item()), а не делал общий, хотя и так по логике вроде не должно было быть одинаково...ну и не вижу других примеров в коде, когда из-за общего написания слов "name" у каких-то разных объектов что-либо совпадало (а объектов много разных с name).

Мне бы хотелось в этом разобраться.

Т.е. если в твоём примере ситуация и понятна, ок, то у меня была один пример назад несколько иная ситуация всё же!
v1 = right_hand_item()
v1.name = "блабла"
&
v2 = on_head_item()
v2.name = "блублу"

и почему же тогда v1.name = v2.name = блублу ?

vasex, и почему твой костыль должен был помочь?

nvc123, звучит хорошо... Но я попробовал заменить таким образом:
Чтобы избавиться от сторонних проверочных классов типа item_for_put_on_1, я решил переносить в функцию item_put_on() не это, а сохранить нужную i !!!
Для этого добавил переменную qqq, которая присвает значение i (это строка - название из словаря, которые перебираются лупом while при поиске вещи, которую игрок хочет надеть), сделал qqq глобальной в обеих функциях.

А затем присваиваю теперь к слоту левой руки или головы не item_for_put_on_1, а уже напрямую значение через словарь (т.е. если бы ты был прав, ошибки быть уже не должно):

left_hand_item_1.name = all_item_names[qqq][0]
left_hand_item_1.body_part = all_item_names[qqq][1]
или
on_head_item_1.name = all_item_names[qqq][0]
on_head_item_1.body_part = all_item_names[qqq][1]

Соответственно подкорректировал все проверки, всё работает, как и раньше, первая вещь без проблем помещается в нужный слот.
Но со второй вещью происходит ровно то же самое, как и раньше, она заменяет имя и в on_head_item_1.name и в left_hand_item_1.name, т.е. опять два шлема в разных частях тела.

Тут в чем-то другом проблема. Такое ощущение, что не вижу чего-то до глупости очевидного.

если что, то . это оператор обращения к содержимому объекта
т.е. меняя item_for_put_on_1.name ты меняешь поле name у объекта записанного в item_for_put_on_1
все объекты хранятся по ссылкам а не по значениям
т.е. в следующем коде все переменные (v1, v2, v3, v4) указывают на 1 и тот же объект

v1 = item_for_put_on()
v2 = v1
v3 = v1
v4 = v2

пока что не могу сказать, в чем конкретно проблема, но посоветую сделать дебаг как запись имен переменных в тхт каждый ход - если переменные действительно меняют названия, станет заметно. Пока думаю, что дело с лупом и массивом all_item_names
(у меня была похожая проблема, но со спрайтами для роглайковских крипов, жуки свиду становились скелетами при появлении первого скелета)
Возможно, while и if друг друга теснят где-то, опять же, видел что-то такое на стаковерфлоу, пока свою проблему исправлял (не на пайтоне, но все же), мб стоит это дело переосмыслить чутка синтаксически

Raised:

Он не оптимизированный, а кастрированный.
Но вообще да, именно на это.

Raised:

Все гениальное - просто. Вот только додумывается до гениальных решений очень мало людей.
А касательно поиска автора - таки да. Когда эта технология выйдет в массы - автор значения иметь не будет.
Все бабло будет снимать владелец патентов наиболее популярной API (лично я ставлю на невидию).

Эта технология разработана epic games и представлена еще год назад.

Это утверждение все еще без пруфов. Полагаю "эта технология" - указатель на оптимизированный рейтрейс+денойз?

Думаю, стоит подметить что идея за технологией предельно простая, потому в поисках автора столько же смысла что и в поисках автора народного фольклора. К слову теперь, когда я до этого додумался, их синхронность больше не кажется столь удивительной. Но пруф все еще жду.

Raised, на юнити оно попало из BRIGADE.
А из юнити оно переехало на UE.
А оттуда уже массово распостранилось и движуху подхватили невидии, мелкомягкие и амд.
И если вкапываться в такие дебри, то это началось еще где-то в 2010х годах.
И да, это ниразу не одновременно с презентацией API этой весной.
И информация это не из секретных архивов КГБ, можешь взять да погуглить.

avuremybe, одновременно анонсировали новые технологии и API.

Эта технология разработана epic games и представлена еще год назад.

Плиз пруф. Я слышал только об OctaneRender, когда Oats Studios начали делать свои мувики на Unity.

Raised, какая синхронность? При чем тут зеленые с красными вообще?
Эта технология разработана epic games и представлена еще год назад.
А майки, амд и невидия просто наперегонки начали делать API под эту технологию, потому что кто первый продвинет в массы - того и бабки.

Зы. Меня одного смущает удивительная синхронность зеленых и красных? Если они и о продуктах своих договариваются, то все как всегда в общем. Забавно что даже приглашенным СМИ на Computex запрещали раскрывать детали представленного железа. То ли потому что хотят дезинформировать народ своими маркетингом и адвертайзингом, то ли чтоб поизображать конкуренцию.

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

видел на ютубе на днях как эти роботы танцевали - выглядят конечно как под кокаином, но в любом случае это технологический прорыв в индустрии.
Cinos, да ради такого я уже пару тяг сделал, кайфую сижу

Месяц назад за это даже тост поднимал. Хорошая вещь, но нескоро её увидим во всей, как мне кажется. А жаль.

BrEd Pitt:

Говоря комнаты я имел ввиду множество различных типов комнат, которые после станут известны.

BrEd Pitt:

Если локация сплошь будет состоять только из канализации, то она будет однотипной и есть вероятность того, что игроку поднадоест. Если часть её будет состоять из таких вот "лабиринтов", то да, но сейчас самое главное создать что-то наподобие такой карты, как в этом алгоритме:

интересность мб как вариативность?
Подразумеваю под этим возможность создания не просто пустых комнат, но и комнат с "колоннадами", т.е. вырезанными участками, евпочя.
про подземелья оно и понятно, что не лабиринты, лабиринты же без комнат. Но в то же время вариативности прибавляет сама возможность создания подземелья, в некоторых случаях близкого к лабиринту (а-ля канализации с карманами и прочие катакомбы)
вопрос в том, нужна ли такая реализация
вообще вот тут pcg.wikidot.com/category-pcg-algorithms про все это добро хорошо расписано, в т.ч. и разнесено по категориям

по сабжу "искусственных".
У нас есть какая-то область (сетка), на которой уже делаем операции расстановок комнат, соединения и т.п. и т.д.
Не могу кластеризовать алгоритмы на категории, так как не понимаю как оценивать их.
Пока можно оценивать сам алгоритм по

• асимптотике
• проходимость (достижимость комнат)
• интересность (скучность? как научно назвать? однотипность?)
• ...

И еще хочу уточнить, что именно уровни - подземелья, а не лабиринты и прочие виды нечисти.

грубо говоря, если алгоритм не допускает создания не в исключительных случаях (когда что-либо в формулах обращается в "подозрительные точки") уединенных комнат или коридоров из ниоткуда в никуда, а также если предложенная под подземелье площадь не сплошь покрыта мелкими комнатами/пещерами и тонкими стенами (но в некоторых случаях, например, с соответствующим сеттингом, это можно сделать фичей), то алгоритм хороший.
Что за подземелье, можно уточнить? Искусственное или естественное? Очевидно, что "хорошее" искусственное подземелье должно иметь минимум (а лучше - и не иметь вовсе) кривых и неправильных ходов. Все должно быть строго и как на чертежах.
"Хорошее" естественное подземелье должно удовлетворять обратному (кэп).
Если речь о "смешанном", то алгоритм, как я видел в некоторых роглайках (сам никогда смешанных не делал, не умею) иногда внушителен за счет проверок и всяких аппроксимаций в разных случаях несоответствий. Т.е. допускает кривые, но в меру, комнаты рядом с природными ходами, и наоборот. Тут код надо видеть, или хотя бы алгоритм

решил проблему,нада в меше выставить норм поочередность модификаций

вот
ага еще как сверхестественное сколько моделей неделал эт 2й раз когда с блендером чтото сверхестественное

Apply Transform не забыл перед тем как скелет прикручивать? Других вариантов что это может быть не знаю - у меня все отлично работает. Если это не что-то сверхсекретное - выложи модель, чтобы можно было своими глазами увидеть что же там происходит на самом деле.

ошибся такая инверсия происходит со всем мешем,хотя автовеса ставяться как надо

Работы предложить не могу, разве что для звуковика. О геймдеве: если есть идеи, рекомендую покопаться в Game Maker и работать над личными проектами, подключая других по мере необходимости.

Как ни странно традишн арты выглядят в разы лучше, чем cg. Пока в игровой индустрии можно рассчитывать разве что на хиден обджект проекты, Ито при наличии качественного портфолио. Качай скилл, и изучай чужие работы, например на артстейшене. И попробуй помоделить в збраше, это поможет лучше понимать объёмы.
И анатомия, это первое что в глаза бросается.. Нужно совершенствоваться вообщем

Мой тебе совет - ищи настоящую работу. Рисуй на заказ.

Впечатляюще, но я не уверен, что у тебя получится найти здесь искомое. К сожалению.

Komkozavr, только вот они пару лет его доводили до такого вида, если не больше. Командой в несколько человек, насколько я знаю.

Вот, учись у них. На майнкрафте сделали сталкер и играют онлайн игроки

Подобная наработка на Юнити или Доте обойдется больше миллиона :)

Думаю, WoW устроит тебя лишь на 40%, ибо:

1. Физика. Ее нет.
2. Множество мелких предметов. Реализовать сложно (см. например костры или интерактивная мебель)
3. Механика боя совершенно иная. Есть пара вариантов, как ее можно улучшить но полноценного нон-таргета не выйдет.
4. Устаревшая (еще и стилизованная) графика

Плюсы WoWa:

1. Защита контента (в зашифрованных MPQ), вся логика - на сервере
2. Поддержка онлайна до 5к
3. Множество наработок для сервера и сайта

ТЕС3МР пару месяцев копал, лично мне он не подошел, тебя на 80% думаю он устроит
Минусы у него примерно такие:

1. Не реализованная автоматическая подгрузка необходимых плагинов. (в след крупном патче)
2. Необходимы серъезные правки баланса ролевой системы, тк все кастомные спелы, зелья и энчанты не поддерживаются.
3. Монетизация. Впринципе возможна, но в отрытом доступе никаких наработок нет.
4. Необходимы постоянные рестарты сервера: убитые НПС, забранные квест предметы и тп.
5. Никакой защиты кастомного контента - плагин файлы можно дерибанить напропалую. Единственное исключение - скрипты на стороне сервера.

Есть и плюсы:

1. Движок - ОрепMW, а значит неустанно разрабатывается и улучшается.
2. Мелкие предметы сохраняются в мире. Но города будут завалены хламом.
3. Удобней создавать и править контент (в игровом редакторе)

Cinos, мир воксельный в своей основе, что накладывает ряд ограничений на рендер и форму блоков, если хочется чтобы это работало быстро. А модели всего остального какраз не велика проблема запихнуть какие угодно, можно даже выковырять из JME3 готовые алгоритмы для костной анимации и немного их причесав заставить все это работать (делал так когда-то давно, результат того не стоит).

Это просто стилизация такая. Но на самом деле, как я понимаю, в майнкрафте вовсе невозможен скининг и костная анимация. У тех самых моделей, которые есть в игре, насколько я знаю, анимированы напрямую прямоугольники, представляющие из себя разные конечности и тому подобное.

Cinos, эта тема с каждым разом становится все интересней и интересней.

prog, хочу заметить, что майнкрафт не воксельный, а полигональный.

drako3y, заменить модели какраз таки проблематичней контроля юнитов - воксельный движок он не очень любит что-то кроме кубиков по форме. Заменить модели персонажей не сложно, но они будут бледно смотреться на фоне кубиков и местного света - правильнее запилить свои, стилизованные под кубики, поменять текстуры блоков на свои и добавить треугольный блок чтобы мир не выглядел таким квадратным там где нет отвесных обрывов.

А контроль юнитов нужно просто написать с нуля и это хоть и не самая простая, но и далеко не самая сложная задача - по факту надо будет добавить возможность отдавать AI мобов команды переопределяющие стандартный механизм принятия решений и реализовать интерфейс для этого. Стратегическая камера что тут что в WoW не получится, если не делать рельеф совсем уж плоским - придется довольствоваться свободной камерой, полетом и телепортацией, но не считая этого, реализовать управление юнитами почти как в варе вполне реально.

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

prog:

drako3y:

Вообщем походу WoW — лучший вариант.

Нееее, лучший вариант под поставленную задачу - майнкрафт - единственный серьезный его недостаток это графоний, который вполне можно исправить со временем, не до уровня WoW, конечно, но до вполне терпимого.

А из основных плюсов:

• возможность работы напрямую с кодом, а не через мемхаки и сильно ограниченные скрипты - очень сильно упрощает жизнь и расширяет возможности
• возможность при необходимости привлечь игроков к строительству локаций, что особенно ценно на раннем этапе, когда нужно не отдельные локации доделывать или переделывать, а всю карту сразу создать
• наличие разнообразного готового инструментария для генерации и редактирования карты
• возможность надергать кусков из существующих модов, которые на данный момент почти все с открытым кодом
• теоретически неограниченный размер бесшовной карты (конечно, для твоих целей карту лучше будет ограничить и заранее заполнить, не полагаясь на автоматический генератор, но в любой момент её можно расширить в любую сторону или подключить еще один мир)
• сравнительно небольшая нагрузка и малый вес (учитывая что карта будет запрещена к редактированию игроками в обычных условиях, а игровые механики требующие частых обновлений карты будут отключены за ненадобностью)
• минимальный вес обновлений за счет примитивной графики и за счет отдачи карты в реальном времени, без необходимости её заранее скачивать

prog:

drako3y:

Вообщем походу WoW — лучший вариант.

Нееее, лучший вариант под поставленную задачу - майнкрафт - единственный серьезный его недостаток это графоний, который вполне можно исправить со временем, не до уровня WoW, конечно, но до вполне терпимого.

А из основных плюсов:

• возможность работы напрямую с кодом, а не через мемхаки и сильно ограниченные скрипты - очень сильно упрощает жизнь и расширяет возможности
• возможность при необходимости привлечь игроков к строительству локаций, что особенно ценно на раннем этапе, когда нужно не отдельные локации доделывать или переделывать, а всю карту сразу создать
• наличие разнообразного готового инструментария для генерации и редактирования карты
• возможность надергать кусков из существующих модов, которые на данный момент почти все с открытым кодом
• теоретически неограниченный размер бесшовной карты (конечно, для твоих целей карту лучше будет ограничить и заранее заполнить, не полагаясь на автоматический генератор, но в любой момент её можно расширить в любую сторону или подключить еще один мир)
• сравнительно небольшая нагрузка и малый вес (учитывая что карта будет запрещена к редактированию игроками в обычных условиях, а игровые механики требующие частых обновлений карты будут отключены за ненадобностью)
• минимальный вес обновлений за счет примитивной графики и за счет отдачи карты в реальном времени, без необходимости её заранее скачивать

Модели можно всегда заменить вроде. Просто заменить на нормальные и будет уже нешахтакрафт, а вот контрить пачки юнитов знать бы как.

drako3y:

Нееее, лучший вариант под поставленную задачу - майнкрафт - единственный серьезный его недостаток это графоний, который вполне можно исправить со временем, не до уровня WoW, конечно, но до вполне терпимого.

А из основных плюсов:

• возможность работы напрямую с кодом, а не через мемхаки и сильно ограниченные скрипты - очень сильно упрощает жизнь и расширяет возможности
• возможность при необходимости привлечь игроков к строительству локаций, что особенно ценно на раннем этапе, когда нужно не отдельные локации доделывать или переделывать, а всю карту сразу создать
• наличие разнообразного готового инструментария для генерации и редактирования карты
• возможность надергать кусков из существующих модов, которые на данный момент почти все с открытым кодом
• теоретически неограниченный размер бесшовной карты (конечно, для твоих целей карту лучше будет ограничить и заранее заполнить, не полагаясь на автоматический генератор, но в любой момент её можно расширить в любую сторону или подключить еще один мир)
• сравнительно небольшая нагрузка и малый вес (учитывая что карта будет запрещена к редактированию игроками в обычных условиях, а игровые механики требующие частых обновлений карты будут отключены за ненадобностью)
• минимальный вес обновлений за счет примитивной графики и за счет отдачи карты в реальном времени, без необходимости её заранее скачивать

prog:

Doc, именно поэтому я пытаюсь обратить внимание автора на альтернативы разработке с нуля - тот-же майнкрафт вполне реально приспособить под его нужды за месяц-два фулл-тайма силами одного мидла, если контент сгрузить на самого автора и добровольцев из числа игроков и время кодера тратить только на код.

Разработка из наработок, на томж юнити.
Или с перефигачиванием игр. Я и не говорил прям с нуля.

Вообщем походу WoW — лучший вариант.
Надо искать и читать, что можно сотворить там.

Doc, именно поэтому я пытаюсь обратить внимание автора на альтернативы разработке с нуля - тот-же майнкрафт вполне реально приспособить под его нужды за месяц-два фулл-тайма силами одного мидла, если контент сгрузить на самого автора и добровольцев из числа игроков и время кодера тратить только на код.

80 т.р. - месячная зарплата мидл программиста. Мидл програмист по определению не тот, кто может проект довести с нуля до конца. Что может сделать 1 человек за месяц - думайте сами.

drako3y, ну да, по извращаться придется чтобы дать возможность комфортно контролировать группы NPC с ГМ-персонажа. Но это в любом случае придется делать с нуля, если в основе не стратегия используется.
В моровинде будет та-же проблема, что и в ВоВ - будет нужен дикий изврат чтобы добиться стратегического режима управления NPC, вне рамок записаных заранее сценариев. Имхо, в этом плане проще всего будет работать с майнкрафтом из всех упомянутых тут вариантов т.к. можно работать напрямую с кодом игры, а не с мем-хаками и ограниченными по функционалу скриптами.

prog:

drako3y, 100-200 человек ты ни на одном готовом бесплатном решении не потянеш, придется или платное брать или с нуля разрабатывать, если речь идет о работе с движком, а не о переделывании игры, которая уже тянет такой онлайн.

ИМХО, с такими требованиями лучше всего смотреть в сторону майнкрафта или сервера ВоВ с модами.
Не представляю себе как в режиме ролевой игры один ГМ управится с сотней игроков одновременно, но это уже другой вопрос.

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

drako3y, 100-200 человек ты ни на одном готовом бесплатном решении не потянеш, придется или платное брать или с нуля разрабатывать, если речь идет о работе с движком, а не о переделывании игры, которая уже тянет такой онлайн.

ИМХО, с такими требованиями лучше всего смотреть в сторону майнкрафта или сервера ВоВ с модами.
Не представляю себе как в режиме ролевой игры один ГМ управится с сотней игроков одновременно, но это уже другой вопрос.

prog:

drako3y, технически задача выглядит не особо сложно, но есть нюансы, которые могут все сильно усложнить.

• кол-во игроков одновременно находящихся на сервере (чем больше верхний предел, тем сложнее будет заставить это стабильно работать)
• предельное кол-во NPC, предметов и прочих динамических объектов на карте (чем их больше, тем больше нагрузка на сервер, вплоть до необходимости вводить срок жизни валяющимся на земле предметам и выгрузки предметов и NPC из зон где нет игрков)
• доступные серверные мощности
• требуемый уровень графики и эффектов (создание моделей, анимаций, текстур, звуков, спецэффектов и прочих ассетов это дело не быстрое и не дешевое)
• геометрический размер карты в метрах (больше карта - больше нагрузка на сервер, вплоть до необходимости разбивать карту на несколько участков и полностью выгружать с сервера части, в которых нет игроков)
• необходима ли защита от читеров (если нет. то это очень сильно упрощает разработку)
• необходимость редактирования карты в реальном времени, а не заранее в редакторе (если большая часть объектов на карте не прикручена намертво болтами к земле, то это дополнительная нагрузка и на клиент и на сервер и значительно усложняет разработку)
• механизм обновления для клиента и частота этих обновлений (большие детализированные карты на современных движках могут легко достигать веса в несколько гигабайт, кроме того все ассеты обычно пакуются в один или несколько больших архивов, которые приходится перекачивать целиком при внесении малейших правок в ассеты в архиве)

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

¤ Кол–во игроков вряд ли будет больше 100–200, а с такой нагрузкой не трудно справиться, староватое железо кента тянуло такой вов серв.

¤ Число днамичных объектов будет нехилым, но можно обойтись без особой физики (как в WoW).

¤ Уровень графики: освещение любое, хоть варкрафтовское. Модели я сам запиливаю, как и музыку, озвучку и прочее. Так, что дело очень даже дешевое, т.к. Сам.

¤ Масштаб большой. Придётся делить на карты.

¤ Читеры, хз даже. Полагаю нет. Это не механ рпг очередная, а подобие реального мира, где все выполняют действия свободно, как мыисвами и поступают в рамках психологии своего персонажа. Такое автоматизировать невозможно, по этому я сам ввожу созданные и описанные игроками вещи (типа кто–то сделал меч, именно такой формы и фактуры) или механизирую действия (типа чувак написал <обвил нитку вокруг ножки стула и когда в комнату вошли, дёрнул за неё> и типа я роняю стул и наношу дамаг вошедшему. как–то так).
То есть там нет моьов и кача, есть рил мир, свобода действий и психология вашего персонажа.

¤ Обновления будут происходить не в реальном времени, а в оффлайне, дозаливкой патчей.