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

Начну с класса player (для шутера все). На самом деле, сложно сказать, что там должно быть, это от игры зависит. У меня как в COD4, ходишь, стреляешь и все. Подбирать с земли нельзя ничего. Поэтому функционал - движения (вперед/назад/стрейф лево-право/прыжок и crouch). Также оружие. Плюс боеприпасы и аптечки. (можно и без аптечек). Также обычно можно использовать обьекты. Я этого не делал - т.е. в целом не предусмотрено чтобы можно было открывать двери и лазать по лестницам. Т.е. как в COD4 - там тоже двери либо открыты всегда, либо дверь открывает бот. Но, все же допустим, можно лазить по лестницам и юзать двери. Это для примера автору топика.

Все, больше ничего игроку и не надо, по факту. По крайней мере, в моем движке. Тогда получается так :

Движения / Movement - это отдельный класс. Т.е. у меня это сделано не в классе игрока (player), а отдельно. Там непосредственно - collision detection, причем - мир отдельно (ландшафт и т.д.) обьекты отдельно. Плюс функция для crouch. По факту - это просто измение параметров бокса, т.е. переход из положения walk и обратно. Также, там происходит управление камерой. Камера у меня тоже отдельным классом сделана. Понятно, что камера взаимосвязана с Movement и работает согласно данным от проверки столкновений в Movement. Для прыжка тоже отдельная функция. В принципе по данному классу это все.

Связь такая - Player -> Movement -> Camera.

Теперь оружие. Каждое оружие сделано отдельно. Т.е. например AK,MP5, DesertEagle и т.д. Это все отдельные классы. В каждом классе оружия свои функции - стрельба, перезарядка, установка параметров, также, если есть - глушитель и прицел. Вызов функции рендера тоже идет здесь. Но - рендер происходит в отдельном классе для анимированных моделей. Т.е. у меня свой формат файла - класс для файла это - загрузка данных из файла, закачка текстур, и рендер. Плюс по мелочам для оружия, например recoil.

Кроме того, есть общий класс - Weapon. Этот класс используется для любого оружия, т.е. здесь идет управление использованием оружия, и рендеринг с предварительной трансформацией вида и т.д. Т.е. все что одинаково для любого оружия - здесь. То что уникально - в каждом классе оружия свое.

Теперь что Player происходит, это - назначение оружия в слоты (2 слота всего), т.е. выдача оружия в начале игры и подьем оружия в игре с земли, с обменом. (типа то что есть - выбросили, новое - подняли.) Также здесь идет тоже самое для боеприпасов - увеличение при поднятии, уменьшение при стрельбе. В принципе все. Почему так? Потому что в player есть функция для поднятия с земли предметов, а поскольку боеприпас это предмет, то поднимается он тоже в этом классе. Если есть вопрос - почему не использовать именно функцию для поднятия предметов, отвечу - у меня боеприпас это отдельный элемент, и к обычным предметам (энтити) не относится. Аптечки также как и боеприпас сделаны.

Ну и связи тогда Player -> Тип оружия и Тип оружия -> Weapon.

И последнее. Двери и лестницы. Я не делал, но если бы : тогда, значит, так - лестницы в класс Movement как особый случай. И еще, если можно находиться в воде или под водой - тогда я бы эти функции тоже занес бы в Movement.
Двери еще проще - сделал бы как отдельный класс. И связал бы так : Player -> Door. Т.е. сделал бы двери как отдельный обьект, специальный. Примерно как я боеприпасы сделал, не стал бы делать дверь как энтити, т.е.

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

На самом деле нет стандартов или типа этого, делаешь так, как тебе удобно. Выписываешь все возможности, параметры и делишь их, или же обьединяешь. Можно например, не делать класс для Movement, а запихнуть это в класс Player.

Остальное (насчет мира) на днях напишу.

В общем, полноценный игровой движок состоит из следующих компонентов:

1. Графический движок.
2. Физический движок.
3. Звуковой движок.
4. Искусственный интеллект.
5. GUI + механизм ввода
6. Менеджер мира.
7. Ядро, которое объединяет предыдущие части.

И необязательные, но желательные:
8. Скриптовый движек.
9. ...

Теперь по-порядку.

Графический движок(ГД) - основная часть игрового движка.
Назначение ГД - рендеринг игрового мира, предоставление визуальной информации. На 99 процентов, в первую очередь, игру оценивают на глаз. Поэтому от того, насколько качественную картинку показывает движок, и насколько быстро он это делает, зависит успех игры(Первое время).
Также ГД может уметь рисовать пользовательский игрерфейс, хотя ГУИ может быть и отдельным компонентом.

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

Больше и подробнее про ГД, на примере Огра, можно прочитать здесь.

Ладно. На сегодня все. Остальное в другой раз. Может быть...

Я не говорил что я дам архитектуру движка. Я сказал что я опишу архитектуру, то есть состав классов плеера и мира. 11-й пост, первые два предложения. Больше я ничего не обещал. Можно это отнести к 6 пункту, менеджеру мира то есть.

Те компоненты, которые ты привел - это известно и так, большинству. И написано об этом достаточно. Или ты считаешь что мне надо было просто перечислить эти 9 или ладно, 12, например пунктов? Может надо было просто дать человеку линки на книги зарубежных авторов?

В чем смысл был бы? Я своими словами рассказал, как я сделал некоторые части движка, как они взаимодействуют между собой. Описывать архитектуру в деталях я не возьмусь, тем более на русском.

Тем не менее, возможно ты прав, и действительно ничего не понятно. И возможно что ожидания были иными, но тем не менее....
Потому что я понимаю под архитектурой (architektūra) подробное описание всех деталей и возможностей, и это не влезет в пост на форуме.

Хмм, продолжай, почему же... Можешь обьяснить лучше - обьясни. Или ты просто высказался в противовес мне, как ты это обычно делаешь?

Добавлено (22.10.2009, 10:16)
---------------------------------------------
WXZRW, я примерно так и представлял движок.
Вот только я всё в башке держу, а не на бумаге.

Ну nilrem уже давал ссылку в этой теме - http://gcup.ru/forum/8-1480-1, там есть : 3D Game Engine Architecture, First Edition и 3D Game Engine Programming, также и другие книги... но на инглише... где на русском и есть ли они я не знаю.

Ну у меня тоже часть в башке, но при этом и часть на бумаге. Нет на самом деле ни стандарта ни 100% работающего метода как что делать. Я вот что скажу - садитесь и начинаете проектировать то что вам нужно по вашим требованиям. Забудьте о книгах, это просто размышления некоего автора, по первой книге - которую я упомянул выше - это просто описание разработки двига Magic... Автор сделал его для себя, решил рассказать об этом и получить профит. Вам же нужно думать самим, как лучше сделать... Все двиги делаются под себя в первую очередь, там может быть что угодно... То есть, книги - это хорошо, но нужно стараться сделать самому и по-своему...

У меня нет простых и понятных всем ответов по программингу... которые можно copy-paste... я могу дать направление движения, не больше...

Не нужно думать, что двиг это некое чудо в перьях, сделанное по непонятным методам и алгосам... Там все проще на самом деле... Не надо усложнять ничего... для меня программинг это просто работа и я не вижу в нем вообще ничего особенного...

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

Нет их на русском. Такие книги стоят пару сотен баксов(За бугром).
Поэтому наши издатели не надеются что их будут брать.
Учи английский.
Хорошая книга по архитектуре:
Jeff Plummer. A FLEXIBLE AND EXPANDABLE ARCHITECTURE FOR COMPUTER GAMES.
На flazx ее нет. В сети можно найти по имени plummer_thesis

Возможно, но имхо кому интересно - уже нашел это в гугле. Имхо большинство вопросов уже обмусолены где-либо.

Ну может не как обычно... Мне показалось что ты высказался и свалил...

Просто мне все это кажется ужасно простым, для меня 21 пост - это очень очевидные вещи, т.е. примерно как рассказывать про то что вода прозрачная. Да и вопрос я понял своеобразно, архитектура - для меня это подробное описание в деталях, как техдокумент. Т.е. я думал что если привести эти пункты, о которых ты говорил - это слишком просто и очевидно.

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

Короче говоря, не могу я научить кого-либо программить... Сам умею, но научить - не могу. Не знаю как и что обьяснять.

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

Понятно. Ну а я год проработал в школе, поэтому привык все обьяснять на пальцах.