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