Пр UBEv4 и дальние планы
Добавлено: 28 сен 2012, 02:54
Господа и дамы (а вдруг?)!
Я был весьма оптимистичен по срокам внедрения UBEv4. Более того - текущая ситуация с UBEv4 делает практически невозможным никакие багфиксы или, тем более, изменения в основном движке - даже косметические. Наверное, я местами сам виноват в таком положении дел - пренебрег какими-то принципами организации работы с кодом. Увы - маэмо що маэмо. Сейчас у меня в рабочем каталоге - куча измененных файлов. Если просто их смержить - наступит ПИЗДА движку. А если не мержить - наступит ПИЗДА UBEv4. У меня все рабочие файлы в локальном GIT-репозитории. Для UBEv4 я переключился на отдельную ветку. Она сейчас НЕ ГОТОВА к мерджу даже с транком. Т.е. я сейчас НЕ МОГУ внести изменения даже в транк. Верне - могу, но это будет очень гемморно. Дело в том, что у меня все автоматизированно и незапланированный мердж порушит систему нумерации версий. В целом - решаемо, но только ради небольшого изменения в коде я делать это не буду. Я вам деже не могу показать результаты текущие в реале - только инфопосты. Потому что показ результатов убьет любой сервер - там в середине обработки атакующих миссий стоит тупо die(); и часть кода просто нерабочая. Так что все изменения откладываются до пост-UBEv4. Вот как только я вернусь в транк - можно будет что-то делать.
Как уже говорилось раньше, я, бля, был вообще сильно оптимистичен в сроках UBEv4... Как, впрочем, почти все время с модулями. Вот, к примеру, я структуры таблиц переписывал раз 50 (буквально). Т.е. сейв/лоад отчета сейчас работает, конечно... Но, бля, я до сих пор не уверен, что не прийдется переписывать еще раз структуру таблиц N-раз! Тупо по ходу меняется концепция того, что нужно сохранять в БД и читать. Основная мысль очевидная - сохранять чисто данные, а не данные, перемешанные с оформлением как в старом движке. А вот концепция реализации капитально менялась несколько раз.
Сначала думал - сохранять только искходные данные, считать бой каждый раз. Потом дошел до рэндома... Концепция поменялась
Следующий раз думал сохранять только первичные данные. Дошел до расчета потерь. Концепция поменялась
В третий раз думал сохранять всю инфу по раундам, считать Аутком по ним. Концепция менялась несколько раз в том плане - какие именно данные сохранять. В итоге все равно уперся в луну
Актуальная на сегодняшний день концепция - сохранять финальные результаы по раунду и бою. Но это я еще не приступил к "Уничтожению"... Возможно, прийдется поменять ОПЯТЬ формат данных
Сразу вижу следующую проблему - А ЕСЛИ БУДЕТ КОНСТРУКТОР?! Я, конечно, закладываюсь на это - и часть видимых отсюда проблем уже снял. Проблема в том, что я вижу только ЧАСТЬ проблем и не вижу их в полном спектре. Т.е. в будущем концепция скорее всего ОПЯТЬ изменится
Вы, возможно, думали - чего я так вожусь долго? Потому что, сцуко, куча нюансов всплывает!
Вот у меня на горизонте планирования видна следующая серьезная проблема - квесты. Скажем прямо: квесты - говно. Было сделано для "что бы было". По уму надо разделить квесты на собственно квесты и ачивки. Собственно квесты пока отложим в сторону - гемморой на четыре жопы, возможно позже напишу - почему.
Давайте посмотри на Ачивки (т.е. "Достижения игроков", см. ВоВ, далее - везде).
Допустим, мы говорим об ачивках по кораблям - как предельном случае. Что бы посчитать реальное количество кораблей - надо считать все корабли в полете и все корабли на планетах. Проблема усложняется тем, что существуют "кастомные" корбали - уникальные корабли для разных серверов. Их добавление чутку сложноватое сейчас, но поддержка имеется на уровне движка. Кроме того, есть сервера, где такие корабли существуют. Да и посчитать корабли в полете - та еще задача! Для этого надо парсить список кораблей с флотов в полете. Есть два решения - тупое и красивое
Тупое - считать по той структуре, что сейчас есть. Т.е. парсить ВСЕ флоты (нам же нужно решение рекордов по ВСЕМ игрокам, да?) и использовать БД-имена новых кораблей. Ну, те, которые прописаны в vars.php типа
'name' => 'misil_launcher'
Плюс - это относительно просто и быстро. Используются текущие структуры БД и код переделывать не надо.
Минус - это будет ПИЗДЕЦ КАК МЕДЛЕННО! Т.е. в реалтайме это не сделаешь по такой схеме.
Таким образом, при решении проблемы "в лоб" можно рассчитывать в лучшем случае лишь на не-реалтаймовые рекорды, обновляемые периодически - как сейчас происходит со статистикой. При чем основная проблема решена не будет, а будет только усугублена: при ревизии системы хранения юнитов прийдется вдобавок ко всему ПОВТОРНО переписывать еще и рекорды.
Промежуточное решение - завести где-то промежуточную таблицу и в ней учитывать изменения юнитов.
Плюс - БД остается та же, но прийдется много писать дополнительного кода.
Минус - прийдется писать дополнительного кода ПИЗДЕЦ СКОЛЬКО! Что бы верно знать количество кораблей надо следить за верфью, за боем, за рынком (при чем это я указал только сферы интереса - фрагментов кода будет значительно больше).
Таким образом, промежуточное решение опять же не решит основную проблему и опять же усложнит код. При чем в этот раз - еще сильнее, чем чисто лобовое решение.
И, наконец, красивое решение. Хранить все юниты в отдельной таблице и выбирать из неё аггрегирующими функциями нужные данные.
Плюс - при правильно настроенных индексах (я вам уже хвастался, что в хнова почти не было индексов, а я тщательно проанализировал все запросы к БД и добавил нужные?) это будет очень быстро.
Плюс - такое хранение юнитов открывает дополнительные возможности для дальнейших модернизаций. Например - для хранения всех юнитов в БД. Как следствие - создание простого админского (т.е. несбалансированного) конструктора юнитов. Любых юнитов - не только кораблей.
Минус - это ПИЗДЕЦ сколько кодирования. Фактически прийдется переписать ВСЁ, что относится к работе с юнитами.
Таким образом, красивое решение - хотя и красивое, но потребует огромной работы по переделке кода. UBEv4 по сравнению с этим покажется мелочью. Впрочем, к этому мы, возможно, вернемся как-нибудь позже.
Плюс красивого решения - расширяемость. Более того - расширяемость за пределы текущих возможностей движка.
Выше я уже приводил примеры. Например, админский конструктор юнитов. Сейчас ОЧЕНЬ сложно реализовать конструктор юнитов - даже уровня админа. Его прийдется делать буквально "через жопу" - чтением/записью PHP файлов и использованием кучи оберток (что бы эти данные не попали в реальный движок раньше срока). Т.е. в целом можно - наработки и концепции есть - но СЛОЖНО. "Сложно" - это значит долго. Это значит - наличие определенного количества ошибок. Большего, чем в случае "простого" решения. В конце-концов - это некрасиво!
Дополнительный плюс красивого решения - это неочевидная возможность сделать реалтаймовую статистику! Методы есть разные. Например - концепция "аккамуляторов" - определенных структур в БД, которые производят накопление информации. Например - о количестве потерянных юнитов. В настоящий момент сложно реализовать такой подсчет - это потребует внесения заметных изменений в код атаки и код ЧР. Добавление аккумуляторов, конечно, так же потребует внесения определенных изменений в код. Однако прелесть данного подхода в том, что после базовых изменений в коде, вводящих поддержку аккумуляторов, добавление нового А. будет очень простым!
Второй уровень - возможность создания полноценных квестов. Тут все еше несколько зыбко и расплывчато - поэтому обойдемся пока без конкретики. Но сам факт такой возможности не могу не отметить.
Есть еще и третий, и четвертый уровни - но там еще меньше определенности. Но факт налицо - изменение в архитектуре хранения юнитов кардинально расширит возможности движка. Как их использовать - это исключительно вопрос фантазии.
Я был весьма оптимистичен по срокам внедрения UBEv4. Более того - текущая ситуация с UBEv4 делает практически невозможным никакие багфиксы или, тем более, изменения в основном движке - даже косметические. Наверное, я местами сам виноват в таком положении дел - пренебрег какими-то принципами организации работы с кодом. Увы - маэмо що маэмо. Сейчас у меня в рабочем каталоге - куча измененных файлов. Если просто их смержить - наступит ПИЗДА движку. А если не мержить - наступит ПИЗДА UBEv4. У меня все рабочие файлы в локальном GIT-репозитории. Для UBEv4 я переключился на отдельную ветку. Она сейчас НЕ ГОТОВА к мерджу даже с транком. Т.е. я сейчас НЕ МОГУ внести изменения даже в транк. Верне - могу, но это будет очень гемморно. Дело в том, что у меня все автоматизированно и незапланированный мердж порушит систему нумерации версий. В целом - решаемо, но только ради небольшого изменения в коде я делать это не буду. Я вам деже не могу показать результаты текущие в реале - только инфопосты. Потому что показ результатов убьет любой сервер - там в середине обработки атакующих миссий стоит тупо die(); и часть кода просто нерабочая. Так что все изменения откладываются до пост-UBEv4. Вот как только я вернусь в транк - можно будет что-то делать.
Как уже говорилось раньше, я, бля, был вообще сильно оптимистичен в сроках UBEv4... Как, впрочем, почти все время с модулями. Вот, к примеру, я структуры таблиц переписывал раз 50 (буквально). Т.е. сейв/лоад отчета сейчас работает, конечно... Но, бля, я до сих пор не уверен, что не прийдется переписывать еще раз структуру таблиц N-раз! Тупо по ходу меняется концепция того, что нужно сохранять в БД и читать. Основная мысль очевидная - сохранять чисто данные, а не данные, перемешанные с оформлением как в старом движке. А вот концепция реализации капитально менялась несколько раз.
Сначала думал - сохранять только искходные данные, считать бой каждый раз. Потом дошел до рэндома... Концепция поменялась
Следующий раз думал сохранять только первичные данные. Дошел до расчета потерь. Концепция поменялась
В третий раз думал сохранять всю инфу по раундам, считать Аутком по ним. Концепция менялась несколько раз в том плане - какие именно данные сохранять. В итоге все равно уперся в луну
Актуальная на сегодняшний день концепция - сохранять финальные результаы по раунду и бою. Но это я еще не приступил к "Уничтожению"... Возможно, прийдется поменять ОПЯТЬ формат данных
Сразу вижу следующую проблему - А ЕСЛИ БУДЕТ КОНСТРУКТОР?! Я, конечно, закладываюсь на это - и часть видимых отсюда проблем уже снял. Проблема в том, что я вижу только ЧАСТЬ проблем и не вижу их в полном спектре. Т.е. в будущем концепция скорее всего ОПЯТЬ изменится
Вы, возможно, думали - чего я так вожусь долго? Потому что, сцуко, куча нюансов всплывает!
Вот у меня на горизонте планирования видна следующая серьезная проблема - квесты. Скажем прямо: квесты - говно. Было сделано для "что бы было". По уму надо разделить квесты на собственно квесты и ачивки. Собственно квесты пока отложим в сторону - гемморой на четыре жопы, возможно позже напишу - почему.
Давайте посмотри на Ачивки (т.е. "Достижения игроков", см. ВоВ, далее - везде).
Допустим, мы говорим об ачивках по кораблям - как предельном случае. Что бы посчитать реальное количество кораблей - надо считать все корабли в полете и все корабли на планетах. Проблема усложняется тем, что существуют "кастомные" корбали - уникальные корабли для разных серверов. Их добавление чутку сложноватое сейчас, но поддержка имеется на уровне движка. Кроме того, есть сервера, где такие корабли существуют. Да и посчитать корабли в полете - та еще задача! Для этого надо парсить список кораблей с флотов в полете. Есть два решения - тупое и красивое
Тупое - считать по той структуре, что сейчас есть. Т.е. парсить ВСЕ флоты (нам же нужно решение рекордов по ВСЕМ игрокам, да?) и использовать БД-имена новых кораблей. Ну, те, которые прописаны в vars.php типа
'name' => 'misil_launcher'
Плюс - это относительно просто и быстро. Используются текущие структуры БД и код переделывать не надо.
Минус - это будет ПИЗДЕЦ КАК МЕДЛЕННО! Т.е. в реалтайме это не сделаешь по такой схеме.
Таким образом, при решении проблемы "в лоб" можно рассчитывать в лучшем случае лишь на не-реалтаймовые рекорды, обновляемые периодически - как сейчас происходит со статистикой. При чем основная проблема решена не будет, а будет только усугублена: при ревизии системы хранения юнитов прийдется вдобавок ко всему ПОВТОРНО переписывать еще и рекорды.
Промежуточное решение - завести где-то промежуточную таблицу и в ней учитывать изменения юнитов.
Плюс - БД остается та же, но прийдется много писать дополнительного кода.
Минус - прийдется писать дополнительного кода ПИЗДЕЦ СКОЛЬКО! Что бы верно знать количество кораблей надо следить за верфью, за боем, за рынком (при чем это я указал только сферы интереса - фрагментов кода будет значительно больше).
Таким образом, промежуточное решение опять же не решит основную проблему и опять же усложнит код. При чем в этот раз - еще сильнее, чем чисто лобовое решение.
И, наконец, красивое решение. Хранить все юниты в отдельной таблице и выбирать из неё аггрегирующими функциями нужные данные.
Плюс - при правильно настроенных индексах (я вам уже хвастался, что в хнова почти не было индексов, а я тщательно проанализировал все запросы к БД и добавил нужные?) это будет очень быстро.
Плюс - такое хранение юнитов открывает дополнительные возможности для дальнейших модернизаций. Например - для хранения всех юнитов в БД. Как следствие - создание простого админского (т.е. несбалансированного) конструктора юнитов. Любых юнитов - не только кораблей.
Минус - это ПИЗДЕЦ сколько кодирования. Фактически прийдется переписать ВСЁ, что относится к работе с юнитами.
Таким образом, красивое решение - хотя и красивое, но потребует огромной работы по переделке кода. UBEv4 по сравнению с этим покажется мелочью. Впрочем, к этому мы, возможно, вернемся как-нибудь позже.
Плюс красивого решения - расширяемость. Более того - расширяемость за пределы текущих возможностей движка.
Выше я уже приводил примеры. Например, админский конструктор юнитов. Сейчас ОЧЕНЬ сложно реализовать конструктор юнитов - даже уровня админа. Его прийдется делать буквально "через жопу" - чтением/записью PHP файлов и использованием кучи оберток (что бы эти данные не попали в реальный движок раньше срока). Т.е. в целом можно - наработки и концепции есть - но СЛОЖНО. "Сложно" - это значит долго. Это значит - наличие определенного количества ошибок. Большего, чем в случае "простого" решения. В конце-концов - это некрасиво!
Дополнительный плюс красивого решения - это неочевидная возможность сделать реалтаймовую статистику! Методы есть разные. Например - концепция "аккамуляторов" - определенных структур в БД, которые производят накопление информации. Например - о количестве потерянных юнитов. В настоящий момент сложно реализовать такой подсчет - это потребует внесения заметных изменений в код атаки и код ЧР. Добавление аккумуляторов, конечно, так же потребует внесения определенных изменений в код. Однако прелесть данного подхода в том, что после базовых изменений в коде, вводящих поддержку аккумуляторов, добавление нового А. будет очень простым!
Второй уровень - возможность создания полноценных квестов. Тут все еше несколько зыбко и расплывчато - поэтому обойдемся пока без конкретики. Но сам факт такой возможности не могу не отметить.
Есть еще и третий, и четвертый уровни - но там еще меньше определенности. Но факт налицо - изменение в архитектуре хранения юнитов кардинально расширит возможности движка. Как их использовать - это исключительно вопрос фантазии.