2. Сама архитектура книг-игр наиболее полно отражается в базах данных
6. База данных позволяет сделать множество вещей для повышения интерактивности книги, например наполнение локаций рандомными монстрами... (как пример)
Не совсем точно. Книга-игра (или квест) замечательно представляются в виде структуры реляционных обьектов. Тот же Мастер Книг в памяти строит именно набор обьектов типа "Параграф", "Переход", "Монстр" и т.п. Но сохраняется все это в виде файла, а не в базу данных. Потому как
1) Книгу игру/квест делает один автор. Совместный труд в режиме реального времени (когда потребуется именно база данных) пока не популярен.
2) Книга-игра меняется только в процессе ее создания. Потом это фиксированный набор сущностей, который не меняется (если только автор не решит что-то кардинально поменять). Сохранения игры/квеста опять же не требуют базы, так как сохраняется вся структура разом.
8. и аргумент: "а уже такое есть...", никогда не останавливал нас разработчиков
Ну, если время девать некуда и не жалко отправить результаты работы "в стол" – то конечно пробуй. Просто новые плееры квестов появляется несколько раз в году. И так же быстро изчезают (ибо авторы не спешат писать под них свои квесты). А вот URQ/
QSP, если не ошибаюсь, видели еще на i386.
7. идею поддерживаю, но движков на C++ и C# просто не нашел а это достаточо интересные языки и возможности этих языков намного больше чем у простите Java…
Не согласен.
1)
QSP – написан на C (на каком точно – не знаю
)
2) С# – ничем не лучше Java, но менее надежен. Точнее – менее надежен не сам C#, а его сервер. Ты никогда не задумывался, почему весь интернет держится на xUNIX, а не Windows?
3) C (C++) – отличный язык для низкоуровневых высокоскоростных приложения. Типа обработчка видео. Но плеер книг-игр 99% времени просто ждет ответ Игрока. Так что вопрос скорости просто не стоит.
А теперь представь, сколько будет гемора перенести плеер, написанный на C, на мобильный телефон? На Mac? Нет, если хочется софт, который будет работать не только на MS Windows XP сервис-пак 3, но и на Маке, Юниксе, ай-фоне и обычном мобильнике – альтернатив Java попросту нет.
3. Постоянное изменение данных в дальнейшем предпоагает наиболее гибкий и удобный интерфейс для создания книг-игр (баз данных)
Дык, это речь уже зашла о редакторе книг-игр, а не плеере. А это уже на порядок больший обьем работы. Но начинать надо с него, потому как руками заколачивать квест в базу никто не будет.
1. Access это наиболее гибкий и простой и мощный инструмент для создания баз данных. .... есть опыт удачных веб проектов где вормат аксеса использовался успешно (правда это были биржевые приложения) но тем не менее.
Хм...ну как бы это...ты
IMHO "несколько" преувеличиваешь способности Access. Это очень простая база данных, расчитанная на небольшие и преимущественно однопользовательские приложения. Чтобы сделать большее, нужно цепляться к нормальной базе класса MS
SQL, Oracle и т.п. (никто бы просто не покупал MS
SQL, если бы все такое же можно было получить на Access). Да и как веб-сервер из Access тоже почти никакой.