Снова про фишки
Добавлено: 13 апр 2012, 00:15
Почему я отвергаю некоторые идеи модулей или корректирую уже существующие? Казалось бы: есть человек, готов заплатить денег за модуль - напиши и будет тебе ЩАСТЬЕ! В чем проблема?! Какая причина? А причин, на самом деле, несколько:
1. "Неинтересно". Основная причина. Модуль не вписывается в мое понимание игры. Т.е. получается "мертвый груз" - модуль, которы постоянно нужно поддерживать, переписывать итд. При чем на моих серверах он использоваться не будет и, мне кажется, что он не будет использоваться больше никем, кроме заказчика.
2. "Невыгодно". Напрямую примыкает к предыдущему пункту. Модуль, который неинтересен никому, кроме цены написания все равно содержит цену дальнейшей поддержки. По большому счету - это издержки альфа-стадии движка. По мелкому счету, это значит, что серьезное изменение структуры модулей повлечет за собой переписывание и неинтересного модуля в частноси. И если за переписывание "интересного" модуля я получу какую-никакую компенсацию за счет последующих продаж (а в идеале - получу профит), то переписывание "неинтересного" модуля - это бессмысленная трата свободного времени.
3. "Неперспективно". Дальнейшее развитие движка приведет к полной несовместимости модуля: по идеологическим причинам (см. "неинтересно"), по причинам безопасности (см. "несекьюрно"), а так же по разным другим причинам, которые тут перечислять слишком долго, но которые всегда принимаются во внимание при оценке перспективности модуля. Например - модификация архитектуры потребует ПОЛНОЕ переписывание модуля (см. "несвоевременно").
4. "Нерентабельно". Модуль потребует такое количество работы, которое непропорционально произведенному эффекту. Цена на такой модуль будет астрономической.
5. "Несвоевременно". У движка есть план развития. Кроме изложенных на форуме "внешних" планов развития (т.е. планов, которые изменят геймплей и/или внешний вид движка) есть еще и "внутренние" планы (т.е. планы, которые почти не повлияют ни на геймплей, ни на внешний вид игры). Внутренние планы касаются общей архитектуры игры. И при изменении этой архитектуры отдельные заявки по модулям могут выйти (и будут выходить) из разряда "неинтересно"-"невыгодно"-"неперспективно"-"нерентабельно". Или же изменение в архитектуре движка даст принципиально новые способы реализации или принципиально новые возможности, которые сделают модуль ненужным. В основном, конечно, речь идет о "нерентабельности". Например - можно попросить меня добавить новый ресурс. Я сразу скажу - "нет". Почему? Потому что система ресурсов - первый кандидат на изменение. Сейчас примерно в большей части кода ресурсы рассчитываются раздельно: отдельно - МКД, отдельно - энергия, отдельно - ТМ. Более того - ТМ и энергия рассчитываются СОВСЕМ отдельно. Т.е. цена юнита в энергии рассчитывается по отдельным процедурам (неунифицированным!), чем МКД. А уж для ТМ - вообще все свое - начиная от начисления и заканчивая ценой. Т.е. вздумай я сейчас сделать корабль, продающийся за МКД и за ТМ одновременно, мне прийдется ПОЛНОСТЬЮ переписать функционал верфи, отвечающий за покупку. И не просто переписать - а добавить полностью отдельные процедуры расчета цены ТМ, никак не связанные ни с текущим расчетом цены МКД, ни с текущим расчетом цены ТМ. Можно будет воспользоваться ранними наработками - но это будет копипаста. Или это обернется унификацией расчета цены за ресурсы. При этом все остальное (начисление ТМ и начисление МКД) останется старым. К чему я все это веду? К тому что, например, сейчас идея о введении нового типа ресурсов будет НЕСВОЕВРЕМЕННОЙ - оно потребует огромных изменений в архитектуре, сравнимых по масштабам (хотя и меньшем в абсолютных единицах - человекочасах) с полным переделыванием архитектуры.
6. "Несекьюрно". Объединение в одном интерфейсе админских и юзерских элементов управления - крайне плохая практика. В принципе плохая. Поэтому я буду избавлятся даже от редактирования новостей в юзерке - все только через админку. И поэтому я не буду принимать заявки на админские действия в юзерском интерфейсе. Вообще, это тесно смыкается с предыдущим пунктом: админ будет отдельным аккаунтом со своим логином и паролем - без планеты и вообще возможности входить в юзерку. Зачем? Что бы действия админа не влияли на игровую ситуацию. Грубо говоря - админ поставил сервер на паузу, а сам пошел шариться по вселенной. А это значит - будет отрабатывать менеджер летящих флотов, апдейтер и пр. и др.
Почему при таком количестве противопоказаний я все равно пишу модули? Дело в том, что я поневоле (ограниченность свободного времени) использую "восходящий" подход - он же "индуктиный метод" - выведение общих принципов из частного. Т.е. архитектура модулей на текущий момент конкретно такая, только потому, что при создании модулей были нужны именно такие фишки. Подход не лишен недостатков: появление новых модулей могут привести к существенному изменению архитектуры модулей в прниципе и, соответственно, повлекут за собой переписывание существующих модулей...
"Если б было у меня времени хотя бы час..." Если бы у меня было достаточно времени (скажем - неделя-две) для СН, я бы воспользовался "нисходящим" ("дедуктивным") подходом и сконструировал бы нормальную, расширяемую архитектуру для модулей. Увы, пока так не получается. Я два раза пробовал спланировать модули "с нуля". Они так и валяются на задворках GIT - вместе с обломками предыдущей версии менеджера флотов v2 и неудачной попыткой написать UBEv4. А дело в том, что все это - и архитектура модулей, и новый менеджер флотов, и UBEv4 - задачи атомарные. Они должны быть решены единовременно, за относительно небольшой промежуток времени и не разбиваются на подзадачи. Нельзя написать "архитектуру модуля", уделяя по часу в день - в итоге больше времени уйдет на то, что бы каждый раз восстанавливать контекст. Нельзя написать менеджер флотов - а потом изменять модули миссий, потому что старые модули будут просто нерабочими. Нельзя "по-кусочку" писать новый UBEv4 - потому что за несолько дней простоя архитектура, конечно, из головы никуда не денется - но вот детали реализации улетучатся и потребуется больше времени на восстановление этих деталей, чем на написание самого движка. Все предыдущие крупные изменения - текущий менеджер флотов, UBEv3 - они сделаны при наличии длинных промежутков свободного времени. В последний свой отпуск, например, была запилена подсистема Губернаторов и временных Наемников - с принципиальным переписыванием кишочков СН.
Собствнно, поэтому я тяну с модулем премиумных аккаунтов. Тот вид, который вы хотите - он требует серьезного напряжения. Грубо говоря - "кодировочный запой" с вечера пятницы до утра понедельника. 40-50 часов кодирования за трое суток. Так, кстати, была создана первая версия модуля "Игроки-Альянсы". Я пока не уверен, что смогу такое выдержать - я недавно болел плюс определенная нагрузка на работе, плюс "хвосты" после болезни. Плюс - багфиксы и усовершенствования движка. В результате к концу недели я уже слегка "выжат" и сил на викендный марафон (с учетом того, что в понедельник - на работу) уже не остается. Поэтому - проявите терпение. Да еще сильно подкосил модуль XSolla. Я его как модуль довел до ума более-менее. Но теперь он требует "обязки" - интерфейс для игрока по платежам. Интерфейс для админа. Плюс - сам модуль нужно довести до кондиции: возможность работы с разными валютами, например. А последнее требует добавление в сам движок поддержку мультивалютных платежных систем. Глупо будет сделать один раз фиксированную поддержку одной валюты, если буквально в следующем входящем модуле платежной системы прийдется опять её переписывать - да еще и переписывать при этом модуль XSolla... Т.е. многое приходится делать "на перспективу" - не только то, что нужно сейчас, но и то, что может потребоваться в ближайшем будущем.
Такие дела.
1. "Неинтересно". Основная причина. Модуль не вписывается в мое понимание игры. Т.е. получается "мертвый груз" - модуль, которы постоянно нужно поддерживать, переписывать итд. При чем на моих серверах он использоваться не будет и, мне кажется, что он не будет использоваться больше никем, кроме заказчика.
2. "Невыгодно". Напрямую примыкает к предыдущему пункту. Модуль, который неинтересен никому, кроме цены написания все равно содержит цену дальнейшей поддержки. По большому счету - это издержки альфа-стадии движка. По мелкому счету, это значит, что серьезное изменение структуры модулей повлечет за собой переписывание и неинтересного модуля в частноси. И если за переписывание "интересного" модуля я получу какую-никакую компенсацию за счет последующих продаж (а в идеале - получу профит), то переписывание "неинтересного" модуля - это бессмысленная трата свободного времени.
3. "Неперспективно". Дальнейшее развитие движка приведет к полной несовместимости модуля: по идеологическим причинам (см. "неинтересно"), по причинам безопасности (см. "несекьюрно"), а так же по разным другим причинам, которые тут перечислять слишком долго, но которые всегда принимаются во внимание при оценке перспективности модуля. Например - модификация архитектуры потребует ПОЛНОЕ переписывание модуля (см. "несвоевременно").
4. "Нерентабельно". Модуль потребует такое количество работы, которое непропорционально произведенному эффекту. Цена на такой модуль будет астрономической.
5. "Несвоевременно". У движка есть план развития. Кроме изложенных на форуме "внешних" планов развития (т.е. планов, которые изменят геймплей и/или внешний вид движка) есть еще и "внутренние" планы (т.е. планы, которые почти не повлияют ни на геймплей, ни на внешний вид игры). Внутренние планы касаются общей архитектуры игры. И при изменении этой архитектуры отдельные заявки по модулям могут выйти (и будут выходить) из разряда "неинтересно"-"невыгодно"-"неперспективно"-"нерентабельно". Или же изменение в архитектуре движка даст принципиально новые способы реализации или принципиально новые возможности, которые сделают модуль ненужным. В основном, конечно, речь идет о "нерентабельности". Например - можно попросить меня добавить новый ресурс. Я сразу скажу - "нет". Почему? Потому что система ресурсов - первый кандидат на изменение. Сейчас примерно в большей части кода ресурсы рассчитываются раздельно: отдельно - МКД, отдельно - энергия, отдельно - ТМ. Более того - ТМ и энергия рассчитываются СОВСЕМ отдельно. Т.е. цена юнита в энергии рассчитывается по отдельным процедурам (неунифицированным!), чем МКД. А уж для ТМ - вообще все свое - начиная от начисления и заканчивая ценой. Т.е. вздумай я сейчас сделать корабль, продающийся за МКД и за ТМ одновременно, мне прийдется ПОЛНОСТЬЮ переписать функционал верфи, отвечающий за покупку. И не просто переписать - а добавить полностью отдельные процедуры расчета цены ТМ, никак не связанные ни с текущим расчетом цены МКД, ни с текущим расчетом цены ТМ. Можно будет воспользоваться ранними наработками - но это будет копипаста. Или это обернется унификацией расчета цены за ресурсы. При этом все остальное (начисление ТМ и начисление МКД) останется старым. К чему я все это веду? К тому что, например, сейчас идея о введении нового типа ресурсов будет НЕСВОЕВРЕМЕННОЙ - оно потребует огромных изменений в архитектуре, сравнимых по масштабам (хотя и меньшем в абсолютных единицах - человекочасах) с полным переделыванием архитектуры.
6. "Несекьюрно". Объединение в одном интерфейсе админских и юзерских элементов управления - крайне плохая практика. В принципе плохая. Поэтому я буду избавлятся даже от редактирования новостей в юзерке - все только через админку. И поэтому я не буду принимать заявки на админские действия в юзерском интерфейсе. Вообще, это тесно смыкается с предыдущим пунктом: админ будет отдельным аккаунтом со своим логином и паролем - без планеты и вообще возможности входить в юзерку. Зачем? Что бы действия админа не влияли на игровую ситуацию. Грубо говоря - админ поставил сервер на паузу, а сам пошел шариться по вселенной. А это значит - будет отрабатывать менеджер летящих флотов, апдейтер и пр. и др.
Почему при таком количестве противопоказаний я все равно пишу модули? Дело в том, что я поневоле (ограниченность свободного времени) использую "восходящий" подход - он же "индуктиный метод" - выведение общих принципов из частного. Т.е. архитектура модулей на текущий момент конкретно такая, только потому, что при создании модулей были нужны именно такие фишки. Подход не лишен недостатков: появление новых модулей могут привести к существенному изменению архитектуры модулей в прниципе и, соответственно, повлекут за собой переписывание существующих модулей...
"Если б было у меня времени хотя бы час..." Если бы у меня было достаточно времени (скажем - неделя-две) для СН, я бы воспользовался "нисходящим" ("дедуктивным") подходом и сконструировал бы нормальную, расширяемую архитектуру для модулей. Увы, пока так не получается. Я два раза пробовал спланировать модули "с нуля". Они так и валяются на задворках GIT - вместе с обломками предыдущей версии менеджера флотов v2 и неудачной попыткой написать UBEv4. А дело в том, что все это - и архитектура модулей, и новый менеджер флотов, и UBEv4 - задачи атомарные. Они должны быть решены единовременно, за относительно небольшой промежуток времени и не разбиваются на подзадачи. Нельзя написать "архитектуру модуля", уделяя по часу в день - в итоге больше времени уйдет на то, что бы каждый раз восстанавливать контекст. Нельзя написать менеджер флотов - а потом изменять модули миссий, потому что старые модули будут просто нерабочими. Нельзя "по-кусочку" писать новый UBEv4 - потому что за несолько дней простоя архитектура, конечно, из головы никуда не денется - но вот детали реализации улетучатся и потребуется больше времени на восстановление этих деталей, чем на написание самого движка. Все предыдущие крупные изменения - текущий менеджер флотов, UBEv3 - они сделаны при наличии длинных промежутков свободного времени. В последний свой отпуск, например, была запилена подсистема Губернаторов и временных Наемников - с принципиальным переписыванием кишочков СН.
Собствнно, поэтому я тяну с модулем премиумных аккаунтов. Тот вид, который вы хотите - он требует серьезного напряжения. Грубо говоря - "кодировочный запой" с вечера пятницы до утра понедельника. 40-50 часов кодирования за трое суток. Так, кстати, была создана первая версия модуля "Игроки-Альянсы". Я пока не уверен, что смогу такое выдержать - я недавно болел плюс определенная нагрузка на работе, плюс "хвосты" после болезни. Плюс - багфиксы и усовершенствования движка. В результате к концу недели я уже слегка "выжат" и сил на викендный марафон (с учетом того, что в понедельник - на работу) уже не остается. Поэтому - проявите терпение. Да еще сильно подкосил модуль XSolla. Я его как модуль довел до ума более-менее. Но теперь он требует "обязки" - интерфейс для игрока по платежам. Интерфейс для админа. Плюс - сам модуль нужно довести до кондиции: возможность работы с разными валютами, например. А последнее требует добавление в сам движок поддержку мультивалютных платежных систем. Глупо будет сделать один раз фиксированную поддержку одной валюты, если буквально в следующем входящем модуле платежной системы прийдется опять её переписывать - да еще и переписывать при этом модуль XSolla... Т.е. многое приходится делать "на перспективу" - не только то, что нужно сейчас, но и то, что может потребоваться в ближайшем будущем.
Такие дела.