Реализация БД (MySQL+PHP и др.) для игры Цена и сроки создания ТЗ: 5000 рублей / от недели (минимум 20 часов). На данный момент имеется 26 таблиц с описанием, согласно которых будет определен тип таблиц (приемущественно InnoDB). Принципиальная схема (технологии и системы передачи данных): Описания таблиц (аспекты содержания таблиц): Примеры вычислений и констант (пхп модуль вычислений и взаимодействий): Сами таблицы разрабатывает заказчик согласно рекомендаций и запросов исполнителя. В ТЗ войдет описательная часть всех происходящих процессов в рамках взаимодействия БД и ПХП, а так же иных процессов: - исходя из исходника таблицы (ее смысла) мы делаем предположения в ТЗ, о том, что таблицы делятся так-то, индексируются так-то, делится на такие-то таблицы, намечаются возможные пути дальнейшей оптимизации (но по идее все изначально должно быть оптимизированным); - далее нам нужны механизмы взаимодействий, так называемый пхп модуль, он является ядром вычислений, относительно простые вычисления, но их достаточно много и существуют проблемы оптимизации данного процесса; - получив некоторое примерное решение по таблицам и взаимодействию между ними мы приходим к вопросу маршрутизации, где нас будет интересовать подробнейшая, постоянно корректируемая схема, где указываются технологии, механизмы, базы, таблицы с их названиями и т.д., т.е. мы имеем схему очень подробную, в которую потом встраиваем элементы и таблицы нужные нам по ходу развития модели; - имея схему и пример маршрутизации и примерный объем вычислений мы можем уже понимать масштаб вычислений на 1 запрос со стороны юнити, запрос один, а операций вычисления много, потому как по итогу выстрела много чего приходится рассчитывать, поэтому это все делается в рамках 1 запроса со стороны юнити, и ряда ответов в рамках 1 пакета Н пользователям по нужным направлениям взаимодействия в самой игре; - имея примерные нагрузки мы можем уже думать как ее можно потенциально оптимизировать и вообще маштабировать систему, и примерно прикидывать потенциал снижения нагрузки, методы вопрос открытый и обсуждаемый, либо через шарды, либо еще как-то, тут нужны будут предложения; - получив понятную всем сторонам схему мы придем к проблеме управления всей системой, делаться это будет заказчиком никак не через пхп ми админ, а все же через отдельный сервис, который внеся изменения решает вопросы обновления инфы в ОЗУ. Так же данный элемент делает систему безопасной от криворукости заказчика при работе с данными в БД (балансировках и т.д.); - важный аспект, это система отчетности, которая является некоторым статистическим аппаратом всей системы, механизм которого будет описан позже, но идея сводится к сбору статистики и созданию отчета на: день, недлю, месяц, квартал, год исходя из единой формы учетов, которая пока не придумана. Когда вышеописанные мероприятия проведены, можно будет говорить о цене самой реализации, потому как будет реальная схема, примерные скрипты и взаимодействие, в общем будет много инфы, на которую можно основываться для реализации задуманного. Само ТЗ - это часть реализации уже, потому как там многое уже описано, как и что реализовывать. Что требуется четко понимать - ТЗ делается в первую очередь для свободы действий заказчика, что бы он мог постучаться с данным ТЗ в любую дверь и понимающие люди ознакомившись с материалом пояснили, что ТЗ сделано очень толково, все ясно и понятно, есть ряд спорных моментов, но в целом все сделано оптимально и правильно. Так же требуется понимать, что заказчик очень заинтересован в том, что бы реализация была за разработчиком ТЗ, потому как это наиболее оптимальное решение с минимумом рисков неисполнения задачи, а так же уровня качества, но тем не менее само ТЗ является страховкой от невозможности договориться между собой о реализации, тем не менее, заказчик будет стремиться к договоренности всеми силами. Важно учитывать так же и то, что заказчик хочет учиться и вникать в построение БД, что бы быть самому в теме, и что бы он мог объяснить самому себе и другим, что мы не применяем яву, т.к. нет специалистов в нужном количестве, а применяем пхп, т.к. и специалистов много, обслуживать потенциально проще, но вместе с тем, имеем риски тормозов и задержек, которые скрываем путем затянутого анимирования процесса взаимодействия в игре (как пример). И так по каждой технологии и таблице, что так-то индексируем потому-то, заказчик это хочет знать, он хочет учиться проектированию БД и должен иметь возможность критики, вопросов и рассуждений на предмет эффективности методов и структур. База данных предполагается для игры создаваемой на Юнити, в которой пошаговый режим боя между игроками (Fallout 2), что потенциально крайне сильно снижает нагрузку на сервер, но маштабировать систему тем не менее будет нужно. Все расчеты взаимодействий происходит на стороне сервера: вычисления, учет и т.д. Сервер: - Intel® Core™ i7-920 Quadcore, 4 физических ядра, 8 потоков (hyper-threading); - 2 x 2 TB 6 Gb/s SATA 7200 rpm/Enterprise (software RAID1); - 48 GB DDR3; - канал от 10 M/mit; - ОС: Debian 6.0. ТЗ необходимо создать по текущим материалам, а затем сформировать предложение по реализации системы с сроками и ценой. --------------------------------------------------... Просим для начала ознакомиться с ТЗ, что бы исполнитель представлял картинку и задавал вопросы по существу. УБИДИТЕЛЬНАЯ ПРОСЬБА !!! Писать сразу в скайп: forexaw.com заказчик решает все вопросы только в скайпе, потому как для него это единственный источник оперативной связи. Для справок прошу писать в скайп: Skype: forexaw.com
Опубликован 14.12.2014 в 11:19 по мск
Прошло времени с момента публикации: более 9 лет
Исполнитель проекта:
