Примеры диаграммы классов для RPG (Ролевая Игра Играющего)

Question

Примеры диаграммы классов для RPG (Ролевая Игра Играющего)

Вы smogли сделать smtng как это (я использовал cin, но вы можете использовать любой другой поток файла):

string line;
while( getline( cin, line ) )
{
 istringstream iss( line );
 int number;
 while( iss >> number )
  do_smtng_with_number();
}

Или:

int number;
while( cin >> number )
{
 do_smtng_with_number();
}

27

class-diagram project-planning class

задан James McMahon 6 August 2009 в 13:10

7 ответов

<tongue_in_cheek_mode_because_it_is_friday>

Просто для начала:

          ----------------                    --------------
          |   Creature   |                    |  Item      |
          |--------------|                    |------------|
          | Name         |                    | Name       |
          | Hp           |                    | Value      |
          | Abilities    |--------------------| Weight     |
          |--------------|                    --------------
          | Attack       |
          ----------------
                 ^
                 |
        ----------------------
        |                    |
----------------    ----------------
|  Hero        |    |  Monster     |
|--------------|    |--------------|
| Level        |    |              |
|--------------|    |--------------|
| KillMonster  |    | AttackAndDie |
| GrabTreasure |    | DropTreasure |
----------------    ----------------

</tongue_in_cheek_mode_because_it_is_friday>

5

ответ дан Toon Krijthe 14 October 2019 в 12:48

совсем другой подход Стива Йегге.

4

ответ дан h0b0 14 October 2019 в 12:48

Посмотрите на Jade's Javadoc , чтобы получить хороший обзор сложной игры :)

3

ответ дан 28 November 2019 в 02:35

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

Многие современные игровые движки отходят от " монолитный объект класса "(или класс Entity, что угодно) и в сторону подхода" мешка компонентов ".

Существует множество книг и статей. В целом:

серия Game Programming Gems (очевидно, в томах 5 и 6 есть статьи о компонентах, и я думаю, что во втором томе тоже могла быть одна)
Конференция разработчиков игр ] на сайте часто есть ссылки на презентации прошлых лет, и это золотая жила для подобных вещей - обычно вы даже можете дешево купить CD / DVD прошлых лет (особенно если вы посещаете)
Архив тематических статей Gamasutra и Game Developer Magazine ] backissues

В частности (некоторые заслуживающие внимания, google "компонент" и "объект" в различных комбинациях, подробнее):

Evolve Your Hierarchy , Mick West
Entity Systems - будущее развития MMOG ; также часть 2 и часть 3
Введение в архитектуру осады подземелий на вики-сайте Gas Powered Games
Система игровых объектов, управляемая данными , Скотт Билас (GDC) 2002)
Ночная инициатива , коллекция библиотек и инструментов с открытой лицензией от Insomniac Games (судя по тому, что я видел, у них одна из самых больших разработок в отрасли)

Каждая из этих статей содержит ссылки на несколько других.

Попробуйте kool-aid, вам может понравиться. =)

11

ответ дан 28 November 2019 в 02:35

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

   +-----------------------------+
   V                             |
[Actor] ------- [Allegiance] ----+
 - risk comfort    - weight
 - temerity

1

ответ дан 28 November 2019 в 02:35

Как насчет чего-нибудь в этом роде:

alt text http://img217.imageshack.us/img217/4886/classwo0.png

Вот еще несколько диаграмм:

4

ответ дан 28 November 2019 в 02:35

Другие вопросы по тегам:

class-diagram project-planning class

Похожие вопросы:

score 49 · Accepted Answer

Я знаю Эммануэля Делогета из GameDev.net, но я не уверен, что выбрал бы его иерархию! Слишком много наследства, недостаточно гибкости.

Если бы я писал текстовую RPG (как я это делал в прошлом), она бы выглядела примерно так (хотя, к сожалению, у меня нет времени на ее составление):

Существа, Комнаты и Предметы, полученные из WorldEntity, с объектами WorldEntity, расположенными в составной структуре, так что предметы могут жить в других предметах, переносимых существами, которые существуют в комнатах. Реализация шаблона посетителя для WorldEntities может работать хорошо.
Классы CreatureType и ItemType, которые содержат данные «class» для отдельных экземпляров Creature и Item, которые ссылаются на соответствующий им объект «type». (например, базовые хитпоинты и статистика в первом, текущие хитпоинты и переходные эффекты во втором). Я мог бы реализовать их в виде прототипов списков свойств, которые копируются в экземпляры Creature или Item при их создании. Вы можете реализовать наследование свойства с помощью свойства «parent», чтобы конкретный экземпляр существа-гоблина мог относиться к CreatureType «воина-гоблина», который содержит родительскую ссылку на CreatureType «универсального гоблина». И так далее.
Выходы, которые принадлежат их комнате, и являются односторонними, и которые детализируют направление движения, различные условия прохождения и т. Д.
Области, которые содержат группы комнат, связанных некоторой логической организацией.
Класс Spawn для указания, где создаются экземпляры Существа и Предмета (например, в какой комнате или в каких координатах), когда они создаются и с какой периодичностью, а также из каких CreatureTypes и ItemTypes. У вас может быть какая-то логика, чтобы немного рандомизировать вещи.
Заклинания, умения, способности и т. Д. Все получены из базового класса действий или интерфейса, который определяет предпосылки (например, текущее положение, очки маны, некоторая степень изучения навыка и т. Д.). Нормальные команды и действия также могут быть здесь, поскольку они часто имеют какие-то требования (например, команда 'sleep' требует, чтобы вы еще не спали.)
Класс FutureEvent, который по сути является обратным вызовом, который вы нажимаете на приоритетную очередь для выполнения в будущем. Вы можете использовать их, чтобы планировать боевые раунды, время успокоения заклинаний, ночные / дневные циклы, что угодно.
Хэш / карта / словарь пар имя-> значение для статистики игрока и предмета. Не безопасно для типов, но вы по достоинству оцените гибкость позже. По моему опыту создание переменных-членов stats работоспособно, но негибко, а наличие специализированных классов атрибутов становится сложным кошмаром при отладке.
Тип модификатора, который содержит имя статистики и значение модификатора (например, +10, + 15%). Они добавляются к вашим существам по мере их использования (например, с помощью эффекта заклинания или с использованием зачарованного оружия) и позже удаляются с помощью синхронизированного FutureEvent или другого события, такого как выполняемая команда.
Специфичные для игры классы, такие как PlayerClass или PlayerRace, каждый из которых описывает класс игрока (например, воин, волшебник, вор) или расу (человек, эльф, гном) и задает начальные значения и пределы статов, списки доступности навыков, специальные полномочия и т. д.
Основные классы интерфейса игрока, которые будут различаться в зависимости от вашего реального типа игры. У вас могут быть классы рендеринга для графической игры, или в MUD у вас может быть класс Connection, отражающий TCP-соединение с клиентом игрока. Старайтесь не допускать в этом всей игровой логики.
Интерфейс сценариев. Большинство ваших команд, заклинаний и ИИ существа могут быть реализованы быстрее с приличным интерфейсом сценариев, и это также сокращает время компиляции. Он также позволяет использовать некоторые отличные возможности отладки и диагностики в игре.

Это была бы базовая структура высокого уровня, которую я бы использовал.