Темой этого лога будет «движок» или «думы об игровой структуре».
Всё очень просто – будет текст с диаграммами, которые не содержат кода, но надеюсь дают понять, как же будет работать сама программа. Не претендую на «это самая крутая организация программы» или «вот как надо делать, учитесь!», скорее лог ориентирован (как и вся серия) на некий диалог с сообществом, ведь среди читателей, возможно, есть те, кто уже делал подобное и\или готов поделиться своими мыслями по этому поводу.

Для начала расскажу про кроссплатформенность, вернее что это значит для моих проектов. Когда выходит новая игра и она «кроссплатформенна», то обычно это значит, что проект выходит, например, на <PC, PS3, Xbox360, PS4. Честно говоря не знаю как труЪ-инди попасть на консольки (насколько я знаю нужна специальная девелоер версия консоли? И аккаунт разработчика, короче, кто знает – поделитесь), поэтому для меня кроссплатформа – это ОС семейства Windows и Linux-подобные, а для Mac ситуация практически аналогичная консолям – нужно спец.железо и статус разработчика (могу быть не прав, поправьте если это не так).

Собственно моя игра должна быть ориентирована на две «платформы» - Windows и Linux (или же SteamOS).
Для каждой операционки нужно будет компилировать проект отдельно - это в лучшем случаи, а в худшем - переписывать значительную часть кода, поэтому логичнее всего избежать двойной\тройной\N-ой работы и свести её к минимуму, а для этого я планирую «распилить» архитектуру приложения так, что часть, зависимая от конкретной платформы была как бы отделена от основного игрового кода.

В Windows каждый элемент графического интерфейса – это «окно», даже кнопка – это «окно», разумеется в рамках кода. Для игры же необходимо минимум одно окно, в которое будет рисоваться сцена, отправляется сообщения ( нажатия клавиш, например) - это немного. Собственно тут нет ничего сложного, «платформозависимая часть» - это специфичный код для ОС, например, создание окна программы, отлавливание различных событий, например, нажатие клавиш, изменение положения мыши, сворачивание или закрытие программы.
Весь код, который будет работать с API(application programming interface) ОС нужно завернуть в более простую "упаковку" (можно сказать, создать свой API), например, функции создания окна, позиционирования его на экране и установке его размера можно разместить в своей функции и назвать её, скажем, CreateAppWindow( тут-параметры ).

Здесь уже нужно «изолироваться» от ОС. Отличным примером общего кода служит набор функций\классов математической библиотеки - различным векторам и матрицам не важно какую ОС вы используете, как и большей части игровой логики. Для набора игр можно определить какие-то базовые структуры, например, игровой объект, сцена, где происходит всё действие или же функции-указания как загружать 3Д модель.
Иногда всё же необходимо работать с ОС, вернее использовать её функции в игровых целях. Например, если необходимо получить список файлов сохранения в какой-то папке – это может сделать ОС, а для простоты использования можем написать функцию (в платформозависимой части), что-то типа GetFilesInDir( path ), а результат такой функции будет список имён файлов, например.

Это уже реализация самой игры, вернее её код. Генерация предметов идёт уже в эту часть.
Помимо всяких специфичных для игры функций, здесь можно написать и жанровые заготовки, например, полёт камеры как в RTS, конечно если реализовывать жанры, то получится ещё один «уровень», что может пригодиться в будущем, если планируется писать кучу игр разных жанров :)

Программа должна показывать на экране картинку - игровую сцену, но как ей это делать? Хотя скорее вопрос «чем?». Я уверен, что вы слышали о DirectX и OpenGL, ведь именно они являются «слоем» между видеокартой и программой, по сути именно они и рисуют. Но какую же лучше библиотеку использовать? Когда-то я использовал DirectX, затем перешёл на OpenGL, думаю и дальше буду использовать OpenGL т.к. он кросплатформенный.

Со звуком аналогичная ситуация, можно взять специфичную библиотеку или найти общее решение. Больше использовал DirectSound (часть DirectX), потом немного программировал с OpenAL, ещё слышал, что есть XAudio для Windows.

Сетевая часть … что? Но ведь в игре не планировался мультиплейр, зачем же тогда сеть реализовывать? А ответ вот такой: даже синглплейр может быть устроен как мультиплейр, конечно это какая-то бредовая фраза, но лучше приведу пример. Надеюсь все знают и играли в Half-Life 2 ( или другие игры на движке Source), а ведь в ней только одиночная игра и при этом реализованная она как клиент-сервер, только вот сервер этот локальный. Я думаю это очень крутая идея – реализовать игру как клиент-сервер и не брать во внимание то, что она только для одного игрока. В чём же прикол такого подхода? Всё просто – более быстрая реализация мультиплейра (если он предусмотрен заранее), просто ввести дополнительные игровые правила и всё. Такой подход даст возможность реализовать "Бродилку" для одного игрока, а через какое-то время сделать, например, мультиплейрные баталии, скажем PvE.

Вот примерная блок-схема программы.

Нет ничего сложного :)

Копирование заключается в консольной части, уж больно мне понравилось как они это сделали - "динамические" переменные программы и различные команды. Возможно вы знаете эти команды, например, "noclip" или "impulse 101". Но не только в командной консоли дело, ещё очень крутой вещью является "биндинг клавиш", например, "bind W +move" (или как-то так). Суть биндинга\привязки заключается в назначении клавише консольной команды, конечно вряд ли смогу использовать всю мощь, которую даёт такой подход, но по крайней мере пользователь сможет сам настроить управление.

На самом деле понятия не имею) Скорее всего, что-то по концептам будет.
Так и не сделал лог#5+ :(
Вообще планировал больше диаграмм и картинок, но как-то не пошло : (