во-первых, игры, как правило, имеют симуляцию в реальном времени
- следовательно, игры имеют циклы обновления
- поэтому игры, как правило, выполняют операции бизнес-логики в микросекундном масштабе.
- следовательно, решения для работы с базами данных - это еще не все, они будут вашим «слоем данных»
(если у вас нет симуляции (например: «скрэббл», «цивилизация», большинство игр на Facebook), это неправда. У грязи обычно нет симуляции, поэтому неясно, с какой стороны забор в вашей игре)
Таким образом, на практике, в играх с высоким уровнем симуляции,
небольшие / непостоянные многопользовательские игры (Quake, Counter-Strike, Starcraft - игры, которые можно запускать на одной машине): решите эту проблему, не имея слоя данных (и если они реализуют сохранения, они делают это как гигантские дампы состояния игры). )
большие многопользовательские игры (mmos - игры, требующие нескольких машин): используйте свое постоянное хранилище данных в качестве канала только для записи (и для восстановления), а затем вложите много энергии в схему разделения данных таким образом что логика симуляции (т. е. бизнес) может получить то, что ей нужно, с задержками порядка доступа к локальной памяти.
несколько цифр для перспективы: если «сервер» обслуживает 500 игроков, а ваша скорость симуляции составляет 15 Гц, то каждый игрок получает 0,13 мкс процессора на игрока за такт. поэтому, если вам нужно, чтобы «огненный шар ударил по чему-либо, этот кадр» должен быть << .13 мс, то есть не достаточно длинным для сетевой передачи или запроса SQL. да, вы можете убрать многие из этих проблем в игровой дизайн - например, «не иметь столкновения» решает предыдущий пример. Но в какой-то момент вы перестаете быть симулятором, хех. </p>
вторая большая разница - это «графика»
графическое программирование сильно отличается от программирования бизнес-приложений. хотя я иногда думаю обо всем программировании как о «взять данные на месте A в формате X и переместиться на место B в формате Y», что относится как к деловому, так и к графическому программированию, графическое программирование по большей части на несколько порядков менее прощающее.
(хотя в качестве краткого изложения обратный расчет конверта помещает проблемы Google-esque в то же ведро:
- игр: управляйте гигабайтами ** графических данных в миллисекундных масштабах == 10 ^ 9/10 ^ -3 == 10 ^ 12
- Google: управление петабайтами данных в дневных масштабах == 10 ^ 15/10 ^ 3 == 10 ^ 12
**: и действительно, игры не могут перемещать такое большое количество данных, поэтому «хитрость» графического программирования заключается в том, как «получить гигабайты графических данных там, где они должны быть в каждом кадре», с реальностью, состоящей лишь в том, чтобы фактически перемещать / манипулировать мегабайтами кадра »- загружать экраны - это общий, но неудачный ответ: (
опять же, это менее актуально, если вы создаете игру с низкими требованиями к графике.
таким образом, игры, как правило, оформляются в терминах «геймплей / графика»
, а не "ui / logic / dal".
При этом, когда я перешел с веб-сайта на игры, мой трехуровневый взгляд на мир (да, тогда у нас было только три уровня), я почувствовал, что многое понял в нашем проекте и привел к развитию «слой доступа к данным» для игрового контента, который был очень успешным во многих проектах (решение проблем игрового мира, таких как удаление данных с диска, управление версиями во время разработки, горячая загрузка и т. д.).
Несмотря на то, что новые разработки будут полезны для вас, ваш предыдущий опыт поможет вам в этом.
относительно вашего запроса на консультацию,
Я бы предложил сосредоточиться на игре с дизайном, который соответствует , точно совпадающему с вашим опытом.
то есть, если вы очень хорошо разбираетесь в базах данных, веб-страницах и расписаниях, создайте игру для электронных таблиц:
http://www.ogame.org/
Если вы хотите немного больше игровой логики и симуляции, сделайте коллекционную карточную игру:
http://apps.facebook.com/warstorm/
, если вы хотите немного более сложного взаимодействия с игроком, посмотрите mmo-scrabble: http://wordsquared.com/
и, если вы хотите изучать графику, начните с одиночной игры:)
используйте методы и технологии, которые вам удобны, посмотрите, где они начинают разрушаться, а затем возвращайтесь сюда и публикуйте свои вопросы и открытия.
веселитесь!