Игровая архитектура для кого-то с фоном в приложениях LOB

У меня есть фон, который почти полностью основан на бизнес-приложениях - веб-сервисах, планировщиках, настольных и веб-интерфейсах для CRM-систем и т.д.

Теперь почти со всеми вышеупомянутыми проектами основные принципы одинаковы:

Определенный уровень доступа к данным, уровень бизнес-логики и пользовательский интерфейс.

Очевидно, что какой-то сценарий требует чего-то немного уникального, но в целом он N-Tier полностью.

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

Какие уроки (если таковые имеются) я должен брать из своего нынешнего опыта и что мне нужно, чтобы учиться снова?

Я предполагаю, что, как и во всем моем опыте, разные типы игр будут иметь разные архитектуры, но все они основаны на одних и тех же основных принципах? Ради аргументов, скажем, я создаю простой MUD (возможно, интерфейс сверху вниз, как и старые игры Zelda) - Это казалось чем-то, что я мог бы использовать для моей 3-уровневой логики для: - сервера с BLL и DAL и клиентского интерфейса; - но я не совсем уверен, правильно ли это - конечно, использование Entity Framework не кажется подходящим, поскольку там очень много накладных расходов при доступе к большому количеству вещей в Db, и я предполагаю, что производительность будет проблемой - например, я предполагаю, что я не хочу постоянно использовать Db для хранения мест игроков, если они меняются 20 + раз/секунду...

Существуют ли шаблоны и методы специально для игровых сценариев?

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

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

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

Ответ 1

во-первых, игры, как правило, имеют симуляцию в реальном времени

поэтому игры имеют петли обновления
поэтому игры имеют тенденцию к операциям бизнес-логики в микросекундовой шкале.
поэтому решения базы данных - это не конец и все ваш "уровень данных"

(если у вас нет симуляции (например: "scrabble", "цивилизация", большинство игр в facebook), это неверно. mud не имеет большого моделирования, поэтому неясно, с какой стороны забор вашей игры включен)

таким образом, на практике, в сильных играх,

малые/непостоянные многопользовательские игры (землетрясение, контрстрел, starcraft - игры, которые могут запускаться на одной машине): решить это, не имея слоя данных (и если они реализуют сейвы, они делают это как гигантские отвалы gamestate )

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

некоторые цифры для перспективы: если "сервер" обрабатывает 500 игроков, а ваша скорость моделирования равна 15 Гц, каждый игрок получает 0,13 мс процессора за игрока за галочку. поэтому, если вам нужно, чтобы "огненный шар ударил все, что этот фрейм" должен быть < < 13 мс, не достаточно длинным для сетевого маршрута или запроса sql. да, вы можете убрать из игры многие из этих проблем - например, "не иметь столкновения" решает предыдущий пример. Но в какой-то момент вы перестаете быть симуляционной игрой, хе-хе.

вторая большая разница - это "графика"

графическое программирование довольно отличается от программирования бизнес-приложений. хотя я иногда думаю о программировании как "беру данные на место A в формате X и переместившись на место B в формате Y", который применяется как к бизнес-процессам, так и к графическому программированию, графическое программирование на многие порядки меньше прощает большинство.

(хотя, как и в стороне, быстрая обратная сторона конверта конверта ставит проблемы с google-esque в том же ведре:

игры: управлять "гигабайтами" графических данных в масштабах "миллисекунды" == 10 ^ 9/10 ^ -3 == 10 ^ 12
google: управлять "петабайтами" данных в "дневных" масштабах == 10 ^ 15/10 ^ 3 == 10 ^ 12

**: и на самом деле игры не могут перемещать столько данных, поэтому "трюк" графического программирования прыгает через обручи "как мы получаем гигабайты графических данных, где это должен быть каждый кадр, с реальностью только для того, чтобы фактически перемещать/манипулировать мегабайтами кадров, - загрузочные экраны являются сообщением, но неудачным ответом: (

снова это менее актуально, если вы делаете игру с низкими требованиями к графике.

Таким образом, игры, как правило, обрамляются в терминах "геймплей/графика"

а не "ui/logic/dal". что, когда я перешел от веб-земли к играм, мой трехуровневый взгляд на мир (да, у нас только было 3 уровня), я почувствовал, что дал много понимания нашему проекту и привел к разработке "уровень доступа к данным" для игрового контента, который был очень успешным в нескольких проектах (решение проблем игрового мира, таких как снятие информации с диска, обработка версий времени разработки, горячая загрузка и т.д.).

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

в отношении вашего запроса на консультацию,

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

т.е. если вы чрезвычайно компетентны с базами данных, веб-страницами и расписанием, создайте игру с электронными таблицами: http://www.ogame.org/

если вы хотите немного больше логики игры и моделирования, сделайте коллекционную карточную игру: http://apps.facebook.com/warstorm/

если вам нужно немного более сложное взаимодействие с игроком, проверьте мемо-скребок: http://wordsquared.com/

и если вы хотите изучить графику, начните с игры с одним игроком:)

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

получайте удовольствие!