Наверное каждый, кто пробовал разрабатывать какие-нибудь экономические симуляторы или стратегии, особенно если по профессии занимается разработкой информационных систем, задумывался о том как удобно было бы создать БД, предзаполнить ее и использовать в игре.
Конечно есть альтернатива в виде сериализации всего и вся, а потом разворачивания этого дела в память, но тогда мы теряем возможность писать логику хранимками на SQL и объем данных ограничен ОЗУ.
Короче, вы поняли к чему я :)
Вопрос: пробовал ли кто-то и что именно использовал?
Может подскажете какое решение?
Мне надо:
- Работа с предзаполненными базами
- Полная поддержка T-SQL
- Работа на большинстве актуальных мобильных платформ (Android, iOS, WinRT, WP обязательно, остальное не особо важно).
T-SQL
С таким требованием остается только MS SQL Server :D
Смотри sqlite. Штатно имеется уже в Android и HTML5.
Есть сборки под разные ОС.
Ну, не только T, но и любой сравнивый по возможностям. Oracle тоже пошел бы :D
sqlite судя по всему единственный вменяемый вариант, да.
Еще нашел некую Ninja DB: поддержка всех платформ через Xamarin, а MSовских через .Net есть; обращения к ней через интегрированные запросы.
Из минусов - платная.
Ну, не только T, но и любой сравнивый по возможностям. Oracle тоже пошел бы
Из серии: посоветуйте электронный микроскоп помощнее. Мне гвоздь забить надо.
Зачем в игре мощная аналитика, распределенная база, маштабируемость по пользователя и прочее-прочее, тем более на мобильных ОС?
Хранимки без проблем можно реализовать и на уровне приложения.
Я даже не уверен, что даже транзакции нужны. База же в монопольном режиме скорее всего будет использоваться, правильно?
Привычка использовать крупные субд :)
Естественно все функции крупных СУБД не нужны, но
а) хранимки хочется настоящие, ибо при каждом вызове парсить и интерпретировать запрос - лишняя трата ресурсов (а значит, горячий телефон и севший аккумулятор)
б) транзакции нужны. например, чтобы посреди хранимки, когда уже сделаны изменения, то можно было их легко откатить. да и телефон может, например, сесть и резко выключиться во время выполнения транзакции - будет битая операция (например, золото потрачено, юнит не куплен).
Кстати, про sqlite говорят, что легко огрести проблемы с кодировками, ну и нормальных хранимок нет - печалит.
а) хранимки хочется настоящие, ибо при каждом вызове парсить и интерпретировать запрос - лишняя трата ресурсов (а значит, горячий телефон и севший аккумулятор)
б) транзакции нужны. например, чтобы посреди хранимки, когда уже сделаны изменения, то можно было их легко откатить. да и телефон может, например, сесть и резко выключиться во время выполнения транзакции - будет битая операция (например, золото потрачено, юнит не куплен).
а) Неужто такие ядреные запросы будут, что время на их парсинг будет огромным? Поддержка кеша запросов то же ресурсы жрет.
б) Всё может быть, всё может статься. Для игры enterprise уровень защиты данных обычно не нужен.
По умолчанию в sqlite используется utf-8, который сейчас стал уже стандартной кодировкой. При желании можно и utf16 использовать.
Привычка использовать крупные субд
Да у вас, батенька, БД-головного мозга! :D
Да по идее то для пошаговой игры смотрю - может и прокатят просто тексты в заготовленных файликах.. Но все же железо разное в телефонах бывает, не хочется мучать тех у кого одно ядро часовыми ожиданиями.
Ну это да, безумный уровень защиты не обязателен, но все же транзакции во многом еще и инструмент, используемый при описании бизнес-логики. "Если а, то откатывайся, если б, то коммит".
Ну и не отрицаю про БД головного мозга :)
Все же для простых целей и правда такой микроскоп как хочется не обязателен.
но все же транзакции во многом еще и инструмент, используемый при описании бизнес-логики
Делай проверку до вставки/изменения данных, чтобы обойтись без constrains (в том числе и FK/PK).
На потерю производительности мобил я бы подзабил - процы сейчас достаточно мощные почти везде, в отличии от видюх.
Вместо БД и текстовых файлов, я бы рассмотрел вариант XML (надо знать потребности, прежде чем советовать, поэтому не настаиваю :))
P.S. Сам DWH-разработчик на Oracle обычно.
Какой-то бред использовать БД для игр. Любой достаточно быстрый интепретатор + Json / Xml / скрипт для хранения данных. Сохранение данных на ключевых событиях - покупка денег, получение levelup'a, сворачивание приложения. Можно почитать как сделали в Battle for Westnoth: http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applica… wesnot-0.html
eyenie
> Какой-то бред использовать БД для игр.
Ты sqlite хоть видел?
Eyenie, если данные такие, что предполагают реляционную модель, а не объектную, то как раз таки БД - самое логичное решение.
Тема в архиве.