Я пришел из фоновой разработки бизнес-приложений, поэтому привык к разработке MVC / n-Tier.
Большинство моих приложений имеют примерно такую архитектуру:
GUI -> BL (which deals with entities) -> DAL (SQL DB)
Теперь я хотел бы написать что-то, что представляет собой нечто среднее между интерактивной историей и симуляцией. Существует постоянный «мир», который позволяет вам воздействовать на объекты / NPC. Состояние объектов / NPC меняется со временем (иногда в результате ваших действий), что впоследствии влияет на параметры. Подумайте Забвение , но в гораздо меньших масштабах без боя
Я знаю, что это масштабный проект, и я знаю, что сам не смогу достичь чего-то вроде сложности современной игры - но это не значит, что я не должен пытаться:)
У меня такой вопрос: какую архитектуру мне использовать?
Мне понадобится библиотека элементов истории - персонажи (NPC), локации, транспортные механизмы, объекты, квесты и т. Д. И т. Д.
Естественно, я бы хотел хранить их в базе данных SQL и получать к ним доступ с помощью структуры сущностей.
Затем мне нужно иметь возможность выполнять действия / события в отношении этих элементов. Это где я неясно. Мой обычный метод состоит в том, чтобы иметь (скажем) NPCManager, который имел бы методы для манипулирования объектами NPC - но это не работает с полиморфизмом.
Я полагаю, что мне потребуется использовать наследование (интерфейсы) для обработки всех функциональных возможностей, которые будут иметь каждый элемент. например:
- Элемент (Базовый объект для элементов истории - эквивалент
Object в .Net)
- NPC (Наследует Элемент)
- Страж (Наследует NPC)
- MountingGuard (Inherits Guard)
- и т.д ...
Тогда я могу сказать:
- Все элементы будут иметь идентификатор
- Все NPC будут иметь идентификатор и имя
- Все гвардейцы будут иметь идентификатор, имя и преданность
- Все конные стражи будут иметь идентификатор, имя, преданность и монтирование
Кажется, это не очень хорошо сочетается с EF - например, у меня не может быть метода NPCManager.GiveClothing(NPC as NPC, ClothingItem as Clothing) - потому что передать его MountedGuard не удастся (в частности, класс будет рассматриваться как NPC который не имеет значения с точки зрения базы данных ...)
Мне также кажется, что у меня должны быть методы для работы с MountingGuards специально на объекте MountingGuard, а не на страже или менеджере NPC.
Должен ли я иметь набор сущностей для хранения информации и совершенно отдельный набор классов для представления данных объекта, сохраняемых сущностями. например:
Entities.MountedGuard
Elements.MountedGuard - same properties as Entities.MountedGuard but also has a `Dismount()` method which affects the associated entity?
так я должен использовать не POCO-сущности? или вообще никаких сущностей (в таком случае, как мне определить «мир»? Я определенно не хочу делать все это в коде)
В настоящее время я даже не рассматриваю, как эти элементы будут отображаться для пользователя - на данный момент простой текст кажется вероятным
Если кто-то может указать мне на подходящую архитектуру или хорошие ресурсы.
Большое спасибо