Mercury13

Такой механизм называется «одна единица компиляции» и вполне имеет право на жизнь: на одном процессоре время полной сборки будет наименьшим, потому так распространяют некоторые библиотеки (SqLite, Google Test). Правда,
игра — обычно масштабный проект, и чем больше будет кода, тем дольше нужно компилировать, чтобы проверить изменения.

Потому код обычно разбрасывают по единицам компиляции (*.cpp) в соответствии с его внутренней логикой, и к каждой единице (кроме точки входа) приписывают хедер (*.h), который показывает, что эта единица делает. Повторяю, только описывает, что делает — весь код в CPP. И в большинстве случаев самый длинный этап сборки — линковка (особенно с оптимизацией по ходу линковки aka LTO).

Единственное, что в 80% случаев не получается закинуть в CPP — это шаблоны.

Чтобы один хедер не подключался несколько раз — есть include guard. Правда, если вы не продумали зависимость между хедерами, может попасться циклическое включение — это вредно, но лишь потому, что программа может не скомпилироваться.

Чтобы не было циклических включений, для сохранения скорее всего потребуются два хедера: один отвечает за собственно процедуру сохранения и подключается к одному-единственному модулю — системе меню. Второй — за какие-то общие функции, которые позволяют сохраняться в абстрактный поток плиточному фону, снаряду, монстру… Называется как-нибудь SaveUtils.h и подключается повсюду.

(Примечание. И SqLite, и Google Test разрабатывались по традиционной схеме, с проектом из кучи CPP. SqLite собирается в один большой *.c автоматикой, и я даже качал традиционный код — на 5-метровом файле некоторые версии Embarcadero вылетали с нехваткой памяти. В Google Test есть файл all.cpp или что-то подобное, в котором #include остальных CPP — пользователь подключает в проект all.cpp, и библиотека отнимает минимум его времени.

Без DirectX или OpenGL никуды, это самые низкоуровневые API, дающие как скорость, так и мало-мальскую совместимость.
Советую использовать тонкую обёртку над всем этим добром вроде SDL: думаю, интереснее будет писать игру, чем решать проблемы с Alt-Tab.
А так, если задаться целью, можно небольшой движок сделать за неделю-две. Остальное лучше оставить на багофиксы и наполнение.
Не советую работать с гексами, и вот почему. Гексы сразу же подразумевают, что игра пошаговая. ИИ замучитесь писать!

И ещё. Систему анимации-то можно за это время написать, но сделать хороший редактор анимаций сложнее. Каждый кадр — отдельная картинка, и всё?

Предварительные расчёты (например, координаты моделей) проводить в типе достаточной точности (и, разумеется, на процессоре). Окончательные — в привычном float.
И, понятное дело, для открытых миров придётся писать свои «велосипеды» по отсечению далёких горизонтов, и Unity в стандартной поставке не уверен, что подойдёт.

Ещё раз. Координаты участников игры записываются в double. Координаты вершин модели — во float. Мы на процессоре проводим начальные преобразования координат, убеждаемся, что координаты заслуживают того, чтобы их рендерить, преобразуем во float и гоним на видяху.

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

Рубиться компьютер на компьютер — помогает в маргинальных случаях и свидетельствует о бедном геймплее. Сложных героев наподобие Ио или Оракула из Доты попробуй отработай. (Хотя все последние герои сложные, начиналось всё ≈2007 с героев поддержки, но потом всяких наделали: и танков, и дамагеров.)

Все начальные подсчёты приблизительные, и примерно такие.

Вот у нас есть гипотетическая Лунная Наездница, которая не имеет длительных дисейблов (зато догонит почти любого), каждые 6 секунд даёт магию на 250hp и раз в секунду даёт удар на 50hp. Вот и получается: за кулдаун нюка она сносит 300 hp. Другими словами, больше урона она наносит руками, чем магией. Сколько должен наносить гипотетический Гном-снайпер, который вообще не имеет магии и бьёт только своим ружьём (с такой же скоростью)? Получается, что 90hp. Многовато, но можно дать Снайперу фору другими методами. Поскольку первые уровни Доты — это «перестрелка на Угре» из-за спин крипов, можно дать ему большую дальность, и он зачморит Наездницу. Можно дать подствольник, который будет эффективен против крипов с первых же уровней.

Особые сложности начинаются, когда в игру входят полубоевые персонажи (дисейблеры, киллеры и прочие). Один держит, второй палит — сколько секунд держать? И, считаю, только под Valve решились основные косяки с Дотой.

Поскольку игра длится в пространстве и времени, надо понимать, как та или иная местность, тот или иной этап игры помогает тому или иному герою. Сможет ли игрок выстоять «не в своей тарелке» и пережить чужой «золотой век»? Какие нужно для этого принять решения? Это больше творчество, чем наука.

Но прежде, чем собирать баланс, надо… 1) Собрать приблизительное видение игры; 2) Сделать прототип; 3) Собрать общую картину баланса — и только тогда можно раздавать характеристики разным персонажам.

В первом приближении (деформации малы, балка лёгкая) — половина параболы.
Если точно — решить можно только численно.

В первую очередь авиасимуляторы. Знаю, что из-за масштабов Земли им приходится справляться с ошибками float: если Земля 12000 км в поперечнике, то единица младшего разряда — полметра.
Первый X-COM имел круглую землю, но полёты были по локсодроме. А вот в опенсорсном ремейке 2014 года полёты уже по большому кругу.
Симуляторы бога от Питера Молиньё: Populous, Black and White. Возможно, и другие симуляторы богов (например, Spore — не проверял).

Я говорю именно про шарообразную карту, а не трубу/тор.

А так — я бы предостерёг от шарообразной земли с открытым миром. 1) Расстояния (глобальная карта с ускоренным временем или без времени не в счёт). 2) Навигация по миру (в том числе понятие «север»), проекция миникарты. 3) В какой-то момент нужно закругляться и выкатывать игру, а в какой-то — выдавать аддон. Тяжеловато будет. Кстати, во всех упомянутых играх мир или замкнутый, или намного больше, чем одна планета.

P.S. Моё определение открытого мира: игра, дающая относительную свободу действий и передвижения, но локальный участок, где орудует игрок/группа, намного меньше мира. В замкнутом мире, наоборот, участник орудует практически по всему «миру», оперативно переходя с одного участка на другой. Есть и пограничные случаи: огромное побережье нового Hitman — открытый мир или замкнутый?

> но этот экран в 10 раз меньше экрана моего ноутбука
Если только по площади — если пропорции сходные, 15" больше 5,5" в 7,43 раза.

И там, и тут единицы измерения — пиксели. Просто у смартфонов больше пикселей на дюйм.
Почему так?
• Мы смотрим на экран с меньшего расстояния.
• Смартфонные API молоды и потому изначально рассчитывались на переменный DPI. Имеющиеся программы не пострадают.
• И в то же время из-за маленьких экранов и больших пальцев плотная компоновка элементов управления не требуется.
• Видимо, HiDPI-экран настольных размеров без битых пикселей будет стоить запредельно дорого.

Иногда размеры меряют в «диалоговых единицах» и «аппаратно-независимых пикселях» (например, 1px в вебе именно что «аппаратно-независимый пиксель», который может быть 2 или 3 реальных пикселя). Но это уже офтоп.

Дело тут вот в чём. Оконные ОС работают в событийном режиме: пришло событие «перерисовать», мы рисуем; пришло событие «щёлкнуть», мы щёлкаем. Но поскольку учебным программам надо быть предельно простыми, куда удобнее написать: нарисовать, дождаться нажатия клавиши — как во времена ДОС, когда процессорное время было полностью вашим от точки входа до передачи управления, когда был прямой доступ к видеопамяти… Для консольных программ всю эту событийщину скрыли, хитрым образом на уровне ОС засинхронизировав два потока: один отвечает за поддержание консольного окна, второй — собственно программа. А Pascal.ABC пришлось наладить простейшую эмуляцию, сделав «видеопамять» в виде внутреннего буфера.

Так что придётся подключать события — см. pascalabc.net/downloads/pabcnethelp/scr/PABCUnits/... — и смотреть, какие в этой абстракции найдутся дыры. А они, по Спольскому, будут обязательно: TCP — это протокол гарантированной доставки, но кто её гарантирует, когда физически выдернули провод…

Рейтинг: рассчитывается по своим формулам и никак не стандартизируешь.
Покупки: на это бэк-энд не нужен (хотя при желании можно тянуть информацию со своего сервера, а не с API покупок).
Так что бэк-энд будет небольшой, ибо 99% работы на клиенте, но будет.

Почему скриптовой язык идет вместе с компилируемыми? Разные задачи?

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

// На состоянии
функ Маятник.ПровестиТакт
  ++кадр;
  если (кадр >= 10)
    кадр = 0;
  УстановитьКадр(кадр);

// На сопрограммах
функ Маятник.Жизнь
  для i=[0..10)
    УстановитьКадр(i)
    НовыйТакт

2. Чтобы геймдизайнеры и прочие непрофессионалы (в программировании, естественно, непрофессионалы) могли свободно корректировать код.

3. Часто игру пишут на готовом движке. А в нём зашит какой-то скриптовый язык — это самый простой способ написать игровой движок, законченный и пригодный к применению программистом куда меньшей квалификации. Так, например, устроен Wintermute Engine (старый, но хорошо известный движок для квестов).

Читал, что плюса, C#, Lua.

• C++: язык с давними традициями в геймдеве. Выразительный код (при достаточном профессионализме) плюс контроль за деструкторами — так что не будет просадок FPS из-за мусорщика. Выбор №1, если нужно написать игру с нуля.
• C#: очень простой в изучении язык общего назначения. Библиотеки для Windows, скорее всего, у пользователя есть изначально. Куча движков, библиотек и фреймворков. Даром, что мусорный — если игра не слишком сложная, просадок FPS не будет (хотя последнего босса Hyper Light Drifter я долго громил — в критические моменты игра тормозила).
• Lua: наиболее известный из скриптовых языков, которые можно реально присоединять к Си-программе, и скрипт будет вызывать функции, написанные на обычном компилируемом языке.

Нужно постольку, поскольку художник понимает ваши почеркушки. В смысле, какие-то знания не помешают, но не самоцель.
Куда важнее (из художественного)…
• Понимание стилей искусства, как исторических, так и современных.
• Умение быстро сфотошопить концепт-рисунок, который и будет техзаданием художнику.
• Умение внятно, словами и зарисовками, объяснить художнику, где он не прав.
• По портфолио понять, брать художника в проект или не стоит.
• Умение собрать из «всякого хлама в интернете» временную картинку, чтобы понять, не будет ли лучше другая метафора или другой стиль.

Бывают игры, вышедшие из графического стиля. Например: Myst, Syberia, Transistor. В них геймдизайнер — в первую очередь художник. Но важно и сделать надлежащий геймплей — то, чего, по-моему, не хватает Transistor.

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

У каждого юнита три одинаковых структуры, renderInfo, bufferedInfo и aiInfo. Там могут быть координаты, курс, HP, ссылка на следующего — всё, что угодно. Ссылка на следующего — это важно, ведь юниты могут появляться и исчезать.

Поток интеллекта работает с aiInfo; где-то здесь есть и код мультиплеера. Закончив шаг, поток захватывает мьютекс и для всех юнитов (понятие «все» определяется по aiInfo) даёт bufferedInfo = aiInfo.

Поток прорисовки захватывает тот же мьютекс и для всех юнитов («все» по bufferedInfo) даёт renderInfo = bufferedInfo. А затем, освободив мьютекс, делает с этим renderInfo что хочет.
Под мьютексом будем сидеть очень мало: ни прорисовки, ни мультиплеера там нет.

Поскольку юнит исчезает из памяти только тогда, когда на него пропадают ссылки во всех трёх структурах, надо делать или объектный пул (т.е. юнит, будучи созданным, остаётся навсегда, но впоследствии этот блок памяти можно будет задействовать на другой юнит), или какие-нибудь «мусорные» указатели наподобие std::shared_ptr.

Такая система аналогична тройной буферизации в прорисовке. Только в видяшной тройной буферизации асинхронно действуют кадры монитора и кадры рендерера; у нас — такты игры и кадры рендерера.

Разбивать интеллект на потоки откровенно тяжело, и в игре с мультиплеером я просто не знаю, как. RTS обычно передают по сети короткие пакеты наподобие «выделить юнитов в квадрате (X,Y) — (X,Y)», «добавить к выделению юнита 1234» и «отправиться в точку (X, Y)». Эти команды, будучи выполненными на разных компьютерах, выполняются одинаково.

Если объединить эти две конструкции — повторяемые расчёты и асинхронный рендеринг — возможны неточности, и, надеюсь, они будут приемлемыми — на экране (renderInfo) юнит попадает в отмеченный квадрат, а в aiInfo уже нет, посколько сдвинулся.

Отдельный вопрос — компенсация пинга в играх по интернету. Не думал пока над этим. Наверно, придётся иметь officialAiInfo и lagCompensatedAiInfo…

ЗЫ. Подсказывают, что такт игры в такой ситуёвине длится порядка 0,1 с, т.е. может продлиться несколько кадров. Тогда во всех этих …info надо описать движение так, чтобы в любой момент получить промежуточное x(t), y(t), yaw(t)… Для танка — bodyYaw(t) и turretYaw(t), для человечка — фазу анимации…

ЗЗЫ. Если игра трёхмерная и вид хоть как-то настраивается, одна из команд игры будет выглядеть «выделить юнитов в квадрате (X,Y) — (X,Y) с матрицей преобразования A».

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

Здесь и в Doom совершенно разные технологии.

Здесь честное 3D, но со спрайтами. Гугли «billboard opengl» (или подставь ту 3D-библиотеку, которой пользуешься).

В эпоху Doom трёхмерные чипы были недоступны, всё программно, силами процессора. Потому трёхмерщина была несколько ограниченная: полы всегда горизонтальны, стены вертикальны, использовалась двухточечная проекция, стены рисовались по столбцам, а полы — по строкам. Чтобы взглянуть вверх-вниз, эта проекция прокручивалась вверх-вниз. Сейчас так писать стоит только для машин, где нет трёхмерных чипов (какие-нибудь калькуляторы и читалки).

Наверно, ещё с жанра roguelike, где неопознанная шмотка была реально страшной: встречаются вредные; надел такую — прилипла, носи, пока не расколдуешь.
По слухам, первый Diablo даже пошаговым был, как обычный «рогалик». Потом переделали.