Мы уже некоторое время готовим новый движок для Виртономики. Основная концепция этого механизма - разделение предоставления данных и их представления. То есть, реализуется некоторый интерфейс (API) который позволяет получать данные из игры, не зависимо от их представления в разметке HTML в вашем браузере.
Я пока не готов дать доступ ко всем функциям нового движка, но могу его предоставить к наиболее необходимым методам, для того, чтобы вы могли разрабатывать скрипты, которые не чувствительны к изменениям дизайна Виртономики. Все данные будут предоставляются в формате JSON.
В этой теме вы можете оставлять свои пожелания: какие функции необходимы в первую очередь для реализации полезных скриптов для нашей игры.
Я не гарантирую, что своевременно буду удовлетворять желания наших уважаемых разработчиков скриптов, так как наши ресурсы для разработки весьма ограничены.
- список категорий продуктов product/categories
- список продуктов product/browse
- список розничных продуктов product/goods
два последних метода могут принимать параметр category_id в качестве фильтра
Наверное, самый ожидаемый метод.
Если вы авторизованы в игре, то можно просматривать информацию о своих предприятиях запросом:
unit/summary?id=<unit_id> - где unit_id это id предприятия
- информация о компании my/company
список предприятий своей компании:
company/units?id=<company_id>
можно передавать параметры pagesize и pagenum для постраничного получения данных
Во всех методах, которые возвращают списки, можно передавать в параметрах к этому запросу, необходимые значения полей в качестве фильтров. Например, запрос: company/units?id=<company_id>&unit_type_id=1817 вернет только офисы.
список контрактов:
по поставщикам unit/sale/contracts?id=<unit_id>
по закупкам unit/supply/contracts?id=<unit_id>
можно передавать product_id в качестве фильтра
финансовый отчет по компании:
company/report/finance/byitem?id=<company_id>
Если вы изменили данные предприятия в виртономике через интерфейс пользователя, то необходимо актуализировать данные предприятия, которые вы получали через API, так как для получения данных в самой виртономике и в новом движке используются разные механизмы кэширования.
Чтобы актуализировать данные предприятия, надо выполнить POST запрос: unit/refresh
в POST данных надо передать id=<unit id> и token=<post token>.
Post token нужно получить с помощью GET запроса token
- информация по зарплатам в городах geo/salary
- информация по трудовым ресурсам geo/labors
Оба запроса могут принимать фильтр geo=<country_id>[/<region_id>[/<city_id>]]. Например, geo=7060 - Казахстан, geo=7060/7063 или geo=0/7063 - регион: Южный Казахстан, geo=0/0/422189 - город Гавана.
- транспорт и стоимость доставки geo/transport
Запрос должен принимать параметры city_id - город отправки или назначения, product_id - товар и geo (аналогично параметру geo для запроса geo/salary) - пункт назначения или отправки.
- различные бонусы в странах geo/country/bonus
- таможенные, экспортные и импортные пошлины geo/country/duty Принимает параметр country_id.
- значения ЕНВД для региона geo/region/envd
- стоимость энергии для региона geo/region/energy
Запросы должны принимать параметр region_id
Наверное, в первую очередь наиболее интересно получение максимального числа данных о предприятии: данные о его расположении, типе, размере, сотрудниках, работниках, их состоянии (в отпуске или нет), всех показателях сотрудников и оборудования (квалификация, качество, количество), данные об установленной технологии, данные о количестве занятых сотрудников, данные о продажах за пересчёт (отдельный запрос и для истории продаж), ценники.
Наверное, в первую очередь наиболее интересно получение максимального числа данных о предприятии: данные о его расположении, типе, размере, сотрудниках, работниках, их состоянии (в отпуске или нет), всех показателях сотрудников и оборудования (квалификация, качество, количество), данные об установленной технологии, данные о количестве занятых сотрудников, данные о продажах за пересчёт (отдельный запрос и для истории продаж), ценники.
Пока вот накидал, так сказать, некоторые начальные вещи с которых можно начать ехать. Есть смысл не делать все сразу прям в лоб как кажется нужным а спросить у народа как будет удобнее. Накидал я то что сейчас имеется и как то было структурировано разделено. Если покажется где то что можно проще/лучше то я только за.
Все квалы топ менеджера одним массивом или словарем где элементы вида:
interface ITopManager {
base: number; // базовая квала
bonus: number; // бонусная квала
code: string; // кодовое обозначение квалификации. It, trading, и так далее
}
Список всех существующих товаров в игре. Формат массив или словарь. Содержимое:
interface IProduct {
name: string;
img: string; // полный путь картинки /img/products/clay.gif возможно не нужно для работы с АПИ
id: number;
}
Так как в игре есть разные товарные группы то запрос товаров может быть и по группам.
Все товарные категории для торговли: Словарь где ключами id категории а содержимое
interface ICat {
id: number; // id категории
name: string; // Автомобильные товары - имя категории
goods: number[]; // список айди товаров которые входят в эту категорию
}
Для хранения на складах товары объединяются в другие категории. Есть еще другие группировки. Пока не понял особо смысла, НО товары для торговли и полный список товаров вообще должны быть обязательно.
Запрос списка городов конечно же. В том формате что есь на форуме сойдет, правда не все поля ясны о чем они. Нужно немного пояснить.
Таможенные пошлины страны для всех товаров в формате словаря с ключами id товара:
interface ICountryDuties {
ip: number; // индикативная цена
import: number;
export: number;
}
Ставки ЕНВД аналогично словарем с ключами это id продукта:
interface IRegionENVD {
envd: number; // ЕНВД
}
Тарифы на энергию тоже словарем где ключик это id товара
interface IRegionEnergy {
price: number; // цена
prodId: number; // тип промышленности, очевидно в игре много видов разделений товаров по группам.
}
Запрос списка юнитов с возможностью запрашивать лишь нужный класс: Офис, Магазины, Заводы, Автосервисы и так далее. Так же запрашивать лишь нужный город, страну. В общем аналогично фильтрам.
В целом группы аналогичные тем что сейчас имеют на главной странице компании.
Возвращаются данные в массиве или словаре. Если в словаре то ключами идут subid юнитов.
Для каждого юнита получаем данные:
interface IUnit {
subid: number;
name: string;
type: UnitTypes; // тип юнита, список типов тоже отдается по запросу.
size: number;
city: number; // айди города
region: number; // регион айди
country: number;
}
Типы юнитов это не классы юнитов. То есть Сфера услуг содержит Парикмахерские,фитнессы и так далее. А класс общий.
Полный список типов Имя=Номер возвращается по запросу.
То есть в целом КАЖДЫЙ уникальный вид юнита должен быть обозван как то и пронумерован. Овцеферма это не Коровник и не птицеферма. Хотя все они есть животноводческие фермы.
enum UnitTypes{
shop=1, office=234 // и так далее соответственно внутренней нумерации типов юнитов.
}
Для юнитов где есть персонал запрос возвращает данные по персоналу. Если персонала нет, тогда вернет null или что то однозначное
interface IEmployeesNew {
empl: number; // число рабов в юните
emplMax: number; // макс число рабов
salary: number; // зарплата
salaryCity: number; // зарплата в городе
qual: number; // квалификация
qualRequired: number; // требуемая квала
qualCity: number; // средняя квала в городе
efficiency: number; // эффективность персонала
holiday: boolean; // в отпуске или нет. Если да, то eff будет -1
};
Для юнитов где есть оборудование получаем данные по оборудованию. Если оборудования нет то вернет null или что то однозначное
interface IUnitEquipment {
equipment: number; // количество установленного
equipmentMax: number; // максимально возможное число
quality: number; // качество установленного
qualityRequired: number; // качество требуемое
efficiency: number; // эффективность оборудования
}
Аналогичное что то для животных нужно отдавать. Еще надо подумать что именно.
Далее каждый юнит в любом случае имеет общие данные вида
interface IMainBase extends IUnit {
efficiency: number; // общая эффективность юнита
innovations: string[]; // список инноваций. Возможно их отдельным запросом забирать.
}
Так же инновации наверное есть смысл в объекте отдавать чтобы там сразу были какие то данные помимо просто имени. Ну может быть номер слота где она стоит, размер юнита к которому применяется, ее цена и цена за ход. Описание. В целом сейчас же есть запрос по конкретному слоту и возвращается список объектов, аналогично можно сделать для уже установленных.
Потом уже каждый конкретный тип юнита будет иметь различающиеся данные. На примере магазина:
interface IMainShop extends IMainBase {
place: string; // район расположения
rent: number; // стоимость аренды
departments: number; // число отделов
employees: IUnitEmployees; // или здесь не пихать а просто запросить отдельно запросом.
visitors: number; // число посетителей
service: ServiceLevels; // уровни сервиса или ТОЧНО сервис числом. Универсально языконезависимо. Или число или ключ
}
Склад:
interface IMainWare extends IMainBase {
specialization: string; // строка или айди спецухи. Чтобы из айди можно было получить текст тоже
filling: number; // % заполненности
capacity: number; // емкость в квадратных метрах.
}
То есть запрашивая информацию по юниту, мы заранее должны понимать какой формат объекта получим. Для разных юнитов будут разные элементы.
Вот это поворт. Как же давно мы это просили.
Это ж и калькулятор под это переделать можно, и скрипты начать писать
Огромное СПАСИБО, за такую благостную весть)))
На вскидку, потом добавлю:
1. Текущая дата на реалме
2. Где и каких в городах госы (кач, сезонность(если есть))
3. Региональные бонусы(регион, товар, процент)
4. Отчеты из раздела "Аналитика" (все)
ПРОСЬБА как нить маякнуть чтобы понятно было что есть ответ в шапке. А то не сказали бы не заметил бы
Да, текущую дату ясно дело поддерживаю )). Остальное в целом тоже, но это уже важность пятой очереди имхо
В списке городов расшифруйте поля:
level
plough_field
x и у
status
В списке регионов:
status
sort
В списке стран:
available
region_id - зачем оно там? вообще не понял
Список категорий сам по себе выходит не нужен если в списке продуктов есть и айди и название. категории можно собрать уже по товарам. Тем более что для торгуемых товаров категории запросом не даются. Имхо можно убрать список категории либо для торгуемых товаров добавит запрос на категории торговли. То есть не зная товарную категорию Сумок я не могу сделать запрос с фильтром по Одежде. Сначала надо загрузить все розничные товары а потом получим уже категорию, нафиг тады делать запрос с фильтром потом? Отфильтрую по месту.
В общем - если вы планируете в запросах отдавать сразу и айди и имена и символы - то отдельно отдавать списки категорий особо нет смысла как видится мне.
Список предприятий содержит только заводы как я вижу. Так что вроде все поля очевидны да не очень. Опять же список индустрий выходит можно получить со списка заводов. Возможно запрос списка индустрий = не актуален. Если список всех типов заводов отдается быстро, один раз запросил и перепаковывай как хочешь - это быстрее чем просить сто раз разные запросы:
Непонятные поля:
need_technology
О типе предприятия:
equipment_id
equipment_product_id
output_min_technologies
output_quality_modifiers
output_quantities
output_labor_per_output
'input_qualities' => '{0,0,0,0,0,0,0}', почему нули? не понятно.
Вообще сия информация БЕЗ рецепта сколько чего подать чтобы на выходе было столько то барахла - пользы не несет. Ну имхо.
Спасибо!
Подключите, пожалуйста, какую-нибудь библиотеку, которая будет генерить Swagger UI страницу. Пример: http://petstore.swagger.io/. Так нам будет гораздо удобнее, и вам легче поддерживать актуальность описания методов.
Кстати, у ответов API сейчас Content-Type=text/html, а не ожидаемый application/json.
В списке городов расшифруйте поля:
level
plough_field
x и у
status
В списке регионов:
status
sort
В списке стран:
available
region_id - зачем оно там? вообще не понял
В городах:
level - уровень развития города
x и y - координаты города (широта, долгота) в градусах * 100
В странах:
region_id - если установлен, то это единственный регион в стране
Остальные поля из этих секций не используются.
mr_Sumkin
Непонятные поля:
need_technology
О типе предприятия:
equipment_id
equipment_product_id
output_min_technologies
output_quality_modifiers
output_quantities
output_labor_per_output
'input_qualities' => '{0,0,0,0,0,0,0}', почему нули? не понятно.
need_technology - использует ли предприятие технологию
equipment_product_id - id товара - оборудования
output_min_technologies - минимальная необходимая технология для выпуска продукции
output_quality_modifiers - модификаторы качества
output_quantities - кол-во выпускаемой продукции
output_labor_per_output - сколько нужно рабочей силы для выпуска продукции
input_qualities - минимальное качество сырья для производства
mr_Sumkin
Вообще сия информация БЕЗ рецепта сколько чего подать чтобы на выходе было столько то барахла - пользы не несет. Ну имхо.
input_quantities - сколько "барахла" надо подать на вход
output_quantities - сколько получится на выходе
Вопрос по запросу по конкретному предприятию:
Я так понял что приходит куча данных которые в целом и не нужны. Особенно по городу региону дублируется то что уже есть в других запросах.
Есть еще много разных полей которые вроде бы дублируются. Это можно убрать будет ненужное? Зачем гонять лишние буквы туда сюда.