Я буду писать про программирование игр, но в целом это может относится и к другим областям точно так же. Состояние игры — это значения переменных. Отладчики позволяют просматривать эти значения, но в достаточно тупом режиме, вот переменная, вот ее значение. Если это указатель, то вот значение того что по указателю, если массив, то вот все 100500 элементов массива, а если это связанный список, то дебаггер про это вообще не знает и ходи сам по указателям. А хотелось бы, вытащить из массива или списка элементы соответствующие какому-то критерию, смотреть только нужные сейчас поля, вытащить какие-то поля из связанных переменных. Возможно поменять какие-то значения прямо в рантайме.
Можно через какой-нибудь рефлекшн собирать значения всех переменных и отдавать их вовне. Ну самый простой вариант сервер внутри себя запускать, к которому подключаться браузером, и в js создавать переменные с теми же именами и значениями и для отладки в консоли браузера на js писать всякие запросы.
А можно изначально хранить все переменные описывающие состояние игры, не как просто члены классов, а в спец.хранилище типа базы данных с универсальным интерфейсом. Тогда можно делать клиент, позволяющий работать с этой "базой данных", эта же база пригодится при создании всяких интерфейсов, чтобы прямо в описании интерфейса писать какие данные в нем должны быть показаны.
Наверняка такое сто раз уже придумано и сделано. Где посмотреть и почитать про такое?
Здравствуйте, Рома Мик, Вы писали:
РМ>Я буду писать про программирование игр, но в целом это может относится и к другим областям точно так же. Состояние игры — это значения переменных.
Только конкретная игра и автор игры знает, как интерпретировать переменные и их значения в конкретной игре, как их сгруппировать для удобства использования, и в чём конкретно это удобство заключается.
Поэтому логично написание отдельного UI и/или журналирования параллельно основному UI игры. Ведь обычно цель этого — разработка, доработка и оптимизация игровой логики и ИИ игры.
Всякие консоли по тильдам — это один из вариантов реализации такого, если этого достаточно.
Использовать БД в косынке — это одно, а вот в какой-нибудь ММОРПГ без этого может быть не обойтись.
Переменные хороши компактностью, доступностью и производительностью. Прикручивание к ним БД хорошо бьёт по этим и другим качествам.
Кроме того, главная функция игры — играть, а просмотр и изменение переменных, настройка логики не должны тратить ресурсы во время выполнения главной функции, т.е. попросту отключаться, а то и отсутствовать.
Здравствуйте, Рома Мик, Вы писали:
РМ>Наверняка такое сто раз уже придумано и сделано
Конечно придумано. Консоль называется. Там и переменные все доступны, и делать с ними можно что хочешь. А еще для прикладной части игры язык берут такой, на котором все это делать удобно. Тот же JS или Lua.
А какова цель, сценарии использования, собственно пользователи?
Что мы используем из того что более менее подходит под ваше описание:
1) Отладка
Современные движки много всего умеют при запуске из редактора. В Unity3d или UE4 вы можете найти игровой объект и поменять значения свойств прямо в редакторе (с ограничениями, в которые легко уложиться).
2) Дизайн
Мы храним все дизайн-данные (т.е. данные, которые не меняются самой игрой, но определяются дизайнерами) в CouchDB. Дизайнеры редактируют данные в специальном редакторе. Игровые сервера подписаны на изменения CouchDB и уведомляют клиентов. Так, стоит дизайнеру поменять, например, базовую скорость юнита, как она автоматически и моментально применится для всех юнитов этого типа для всех подключенных клиентов. Ну и да, в редакторе есть поддержка js и много всего.
3) Комьюнити менеджмент
Чтобы CM могли просматривать и редактировать состояния игроков (в том числе онлайн) — игровые сервера предоставляют json rest сервис. CM используют веб-фронтенд.
4) Игроки
Консоль, дебажное UI. Вообще нужно очень хорошо подумать, прежде чем давать что-то игрокам.
Разные сценарии использования — разные подходы.
РМ>... прямо в описании интерфейса писать какие данные в нем должны быть показаны.
Это верная и важная мысль. Все, что нужно инфраструктуре должно быть либо помечено метаданными прямо в коде, либо в IDL (из нашего IDL мы генерируем очень много — код типов для таргет-языков, методы сериализации, сетевые сервисы, схемы для редакторов, xsd для xml, в ближайших планах — sql-миграции, так как источник генерации один то и вся инфраструктура не теряет актуальности). Если где-то добавить лишние шаги, необходимые для поддержания актуальности инфраструктуры (схемы данных, консольных комманд, чего бы то ни было) — и она моментально устаревает.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
