Я знаю Эммануэля Делогета из GameDev.net, но я не уверен, что выбрал бы его иерархию! Слишком много наследства, недостаточно гибкости.
Если бы я писал текстовую RPG (как я делал в прошлом), она бы выглядела примерно так (хотя, к сожалению, у меня нет времени на ее составление):
- Полученные Существа, Комнаты и Предметы
от WorldEntity, с WorldEntity
объекты расположены в Композитный
структура, так что предметы могут жить в
другие предметы, которые несут существа,
которые существуют в комнатах. Внедрение
шаблон посетителя для WorldEntities
может хорошо работать.
- Классы CreatureType и ItemType
которые содержат данные «класса» для
Индивидуальное Существо и Предмет
случаи, которые ссылаются на их
соответствующий объект типа. (например, база
точки попадания и статистика в первом,
текущие хитпоинты и переходные эффекты
в последнем). Я мог бы реализовать это как
прототипные списки свойств, которые получают
копируются в экземпляры Существо или Предмет, когда
они созданы. Вы можете реализовать свойство
наследование через «родительское» свойство, так что
конкретный экземпляр существа гоблина может относиться к
«Воин Гоблин» CreatureType, который содержит
родительская ссылка на «универсальный гоблин» CreatureType. И так далее.
- Выходы, принадлежащие их комнате, и
один путь, и какие детали направления
проезд, различные условия прохождения и т. д.
- Области, которые содержат группы связанных комнат
какой-то логической организацией.
- Класс Spawn, чтобы определять, где Существо
и экземпляры Item созданы (например, какая комната,
или по каким координатам), когда они создаются и
с какой частотой и с
какие CreatureTypes и ItemTypes. Ты можешь иметь
здесь есть некоторая логика, чтобы немного рандомизировать вещи.
- Заклинания, умения, способности и т. Д.
все производные от базового класса Action
или интерфейс, который определяет предпосылки
(например, текущая позиция, очки маны, некоторые
степень освоения навыка и т. д.). Нормальный
команды и действия могут идти сюда, так как они
часто тоже есть какие-то требования
(например, команда «сон» требует, чтобы вы не
уже спит.)
- класс FutureEvent, который по сути
обратный вызов, который вы нажимаете на приоритетную очередь
выполнить в будущем. Вы можете использовать их для
график боевых раундов, время успокоения заклинаний,
ночные / дневные циклы, все что угодно.
- Хэш / карта / словарь пар имя-> значение для
статистика игроков и предметов. Не типобезопасно, но
Вы оцените гибкость позже. В моем
опыт создания статистики членских переменных
работоспособный, но негибкий и имеющий специализацию
классы "атрибута" становятся запутанными
кошмар при отладке.
- Тип модификатора, который содержит имя статистики
и значение модификатора (например, +10, + 15%). Эти
добавляться к вашим существам по мере их использования
(например, через эффект заклинания, или с помощью
зачарованное оружие) и снимают позже
по времени FutureEvent или какого-либо другого события, такого
как выполняемая команда.
- Классы, специфичные для игры, такие как PlayerClass или
PlayerRace, каждый из которых описывает класс игрока
(например, воин, волшебник, вор) или раса (человек, эльф,
карлик) и установить начальные значения статов и лимиты,
списки наличия навыков, специальные способности и т. д.
- Основные классы интерфейса проигрывателя, которые будут различаться
в зависимости от вашего фактического типа игры. Ты можешь
иметь классы рендеринга для графической игры, или
в MUD у вас может быть класс Connection
отражает TCP соединение с клиентом игрока.
Старайтесь не допускать в этом всей игровой логики.
- Скриптовый интерфейс. Большинство ваших команд, заклинаний,
И ИИ существа могут быть реализованы быстрее с
достойный интерфейс сценариев, и он сохраняет время компиляции
вниз тоже. Это также позволяет выполнять отличную отладку в игре.
и диагностические возможности.
Это была бы базовая структура высокого уровня, которую я бы использовал.