А в 2005 нам еще полным ходом приходилось выпускать версию под S40 с ее MIDP 1. Так что я бы сказал, что жесткие ограничения по JAR приходилось терпеть практически весь цикл жизни J2ME игр.
На скорости работы кол-во классов сказывалось не сильно, если правильно помню. Только более длинные цепочки вызовов могли повредить. Но вот места в оперативке отдельные классы жрали катастрофически много, поэтому старались уместить все в минимально разумном количестве:
Стартовый класс со всей логикой инициализации
Класс меню
Класс работы со звуком и музыкой(часто подменялся для разных девайсов)
Класс спрайта
Класс тайлового бэка(использовался и для игры и для заставки)
Класс со всей игровой логикой. И в нем уже встроенные FSM на логику разных объектов массивы с их позициями стейтами и тд. В нем же все общая логика отрисовки.
Реверс инженерил пару игр от Gameloft того времени, у них была плюс-минус похожая структура.
Чтобы критиковать UX, надо в нем хоть немного разбираться. У мобильных устройств, действительно, есть некоторые проблемы с UX. Но это далеко не тот бред, который описан в статье. И стоит хоть немного вникать, почему было принято то либо иное решение, а не просто повторять как мантру "в 70-ых было лучше". И нет, лучше не было. Было отвратительно плохо, по сравнению с сейчас(тем более на стороне ссср и его остатков).
Хотя уверен, что данное нытье найдет своих поклонников, а меня заминусуют)
Согласно роликам на ютубах, народ с MJ уже тоже так наловчился извращаться, что получает то, что хочет. Хотя, конечно, прикручивание дополнительного набора нейронок типа той же controlNet дает очень неплохой буст.
А вот по красоте картинки SD пока до коммерческих вариантов не дотягивает, увы. Это, конечно же, вкусовщина, но все же.
С чего это вдруг SD такая могущественная, если технология "представления" плюс-минус та же? Интерфейсы могут гораздо больше, не спорю, и развиваются быстрее, именно за счет того, что она опен сорс. Но тот же апскейл можно другой нейронкой делать без проблем.
Канбану нужен хороший руководитель, или очень профессиональная команда. Скрам вытянут даже те, у кого слюна изо рта капает. Поэтому проще выбрать Скрам. Ну и да, вокруг Канбана все равно нужно крутить какой-то процесс, так-как задачи у тебя обычно не типовые. Благо Канбан это позволяет легко сделать.
Скрам - отличная соковыжималка для джунов. "Мы же все оценили и подписались сделать это за две недели, давайте же теперь поднапряжемся." С одной стороны держать команду в тонусе все время, не так уж и плохо. С другой, те кто не умеют грамотно оценивать задачи - попадают в адские условия морального давления.
Я ни разу не видел чистый скрам. Обычно со временем добавляют менеджера. А еще накидайте роадмап на год, очень нужно. Ну и продукт оунер уже всем пообещал, что фича точно выйдет в следующем месяце, а вы ее еще даже не пытались оценивать. Хотя друг рассказывал, что бывает и чистый Скрам :D
Так, на подобной короткой, дистанции, для оценки будет та же "чуйка", не более того. Где гарантия, что на новом проекте велосити будет той же, даже если команде повезло не переформировываться?
И обычно невозможно оценить сложность последних задач, пока не сделаны первые. Ну только если очень повезло и проект строго линейный, без зависимостей.
В реальном бою будут присутствовать человеки и эффекты, иногда в больших количествах. Понимаю, что для мобил эффекты гораздо больнее чем для PC, но все же и у вас кусок перфы выедать будет достаточно приличный. Никто не мешает, модели солдат проверять отдельно и прикидывать суммарную нагрузку, но в статье это не указано. У нас на карту левел дизайнеры закидывали юнитов в какие-то точки уровня, чтобы имитировать хоть какую-то нагрузку, но это не обязательно, если есть общий тест боя.
А вот что действительно желательно это тест полного боя, причем так, чтобы сетевой код в нем тоже участвовал(какая-никакая, а тоже нагрузка на CPU). Тут два варианта:
1) Написать реплеи. Это делается не так уж сложно, хоть и кажется огромной задачей. Даже на кастомном движке. Гораздо сложнее их поддерживать, чем написать. Нам, например, пришлось писать отдельный декомпилятор в текстовый формат и компилятор обратно, для реплеев. Чтобы можно было подменять куски логики. В теории можно ввести версии реплеев, и научить игру саму проводить конвертацию к последней версии, но вот это уже выглядит как что-то долгое.
2) Написать скрипт имитирующий бой. И дальше либо пролет камеры через этот бой, либо "проход игрока". Тут главное, чтобы все было максимально честно на стороне клиента, и не пропускались обсчеты, которые происходили бы в случае сетевой игры.
Покушав как следует реплеев, я склоняюсь к тому, что скрипты все же удобнее. Но со скриптами дела имел мало, возможно не вижу каких-то подводных камней.
Плюс, что вам мешает запускать найтили тест перфы(даже хотя бы тот который у вас есть), и рисовать графики? Может вы это и делаете, но в статье про это ни слова. Хотя вроде как, тоже часть автоматизации перф тестов.
Ну и там всякие тесты скорости загрузки уровней, тесты адекватности коллизий(хотя это можно отнести к валидации), тесты на утечки памяти и тд.
Спешу огорчить, вы тестировали не производительность игры, как указано в заголовке, а производительность карты. Это, честно говоря, очень мало и достаточно печально.
www.youtube.com/watch?v=nfxDIkLE3hs
Два с половиной года.
Но справедливости ради, стоит сказать, что команда у них менялась от 40 до 75 человек. Думаю большинство подтянулось, когда пора было создавать контент.
Сколько точно у ребят, я не знаю :) Ну и тут, пока, только софтланч. Возможно года два до релиза и получится.
Чтобы не попадать в пушку врага, нужно не целиться в пушку врага.
Обычно это так работает.
А попадание в пушку, на сколько я помню, всегда идет без урона. Плюс там маска оридия, все дела.
Зачем называть статьи невпопад?
Были. Но не особо массовые.
В 2007 уже iPhone вышел, если что.
А в 2005 нам еще полным ходом приходилось выпускать версию под S40 с ее MIDP 1. Так что я бы сказал, что жесткие ограничения по JAR приходилось терпеть практически весь цикл жизни J2ME игр.
На скорости работы кол-во классов сказывалось не сильно, если правильно помню. Только более длинные цепочки вызовов могли повредить. Но вот места в оперативке отдельные классы жрали катастрофически много, поэтому старались уместить все в минимально разумном количестве:
Стартовый класс со всей логикой инициализации
Класс меню
Класс работы со звуком и музыкой(часто подменялся для разных девайсов)
Класс спрайта
Класс тайлового бэка(использовался и для игры и для заставки)
Класс со всей игровой логикой. И в нем уже встроенные FSM на логику разных объектов массивы с их позициями стейтами и тд. В нем же все общая логика отрисовки.
Реверс инженерил пару игр от Gameloft того времени, у них была плюс-минус похожая структура.
Чтобы критиковать UX, надо в нем хоть немного разбираться. У мобильных устройств, действительно, есть некоторые проблемы с UX. Но это далеко не тот бред, который описан в статье. И стоит хоть немного вникать, почему было принято то либо иное решение, а не просто повторять как мантру "в 70-ых было лучше". И нет, лучше не было. Было отвратительно плохо, по сравнению с сейчас(тем более на стороне ссср и его остатков).
Хотя уверен, что данное нытье найдет своих поклонников, а меня заминусуют)
Еще иногда объекты сразу не удаляют/добавляют, а только помечают на удаление/добавление.
Плюс один, к тому что стоит поменять название.
И хотелось бы сравнение сложности получения консистентных изображений.
Согласно роликам на ютубах, народ с MJ уже тоже так наловчился извращаться, что получает то, что хочет. Хотя, конечно, прикручивание дополнительного набора нейронок типа той же controlNet дает очень неплохой буст.
А вот по красоте картинки SD пока до коммерческих вариантов не дотягивает, увы. Это, конечно же, вкусовщина, но все же.
С чего это вдруг SD такая могущественная, если технология "представления" плюс-минус та же? Интерфейсы могут гораздо больше, не спорю, и развиваются быстрее, именно за счет того, что она опен сорс. Но тот же апскейл можно другой нейронкой делать без проблем.
Ну я больше про аплоад заапскейленых предыдущих генераций. Но сиды тоже часть этого извращения, да.
Что-то похожее на догенерацию в миджорней есть, хоть и сделано через одно место.
Три мысли на тему:
Канбану нужен хороший руководитель, или очень профессиональная команда. Скрам вытянут даже те, у кого слюна изо рта капает. Поэтому проще выбрать Скрам. Ну и да, вокруг Канбана все равно нужно крутить какой-то процесс, так-как задачи у тебя обычно не типовые. Благо Канбан это позволяет легко сделать.
Скрам - отличная соковыжималка для джунов. "Мы же все оценили и подписались сделать это за две недели, давайте же теперь поднапряжемся." С одной стороны держать команду в тонусе все время, не так уж и плохо. С другой, те кто не умеют грамотно оценивать задачи - попадают в адские условия морального давления.
Я ни разу не видел чистый скрам. Обычно со временем добавляют менеджера. А еще накидайте роадмап на год, очень нужно. Ну и продукт оунер уже всем пообещал, что фича точно выйдет в следующем месяце, а вы ее еще даже не пытались оценивать. Хотя друг рассказывал, что бывает и чистый Скрам :D
Так, на подобной короткой, дистанции, для оценки будет та же "чуйка", не более того. Где гарантия, что на новом проекте велосити будет той же, даже если команде повезло не переформировываться?
И обычно невозможно оценить сложность последних задач, пока не сделаны первые. Ну только если очень повезло и проект строго линейный, без зависимостей.
К несчастью, только, гейм дизайна тут нет, увы...
В реальном бою будут присутствовать человеки и эффекты, иногда в больших количествах. Понимаю, что для мобил эффекты гораздо больнее чем для PC, но все же и у вас кусок перфы выедать будет достаточно приличный. Никто не мешает, модели солдат проверять отдельно и прикидывать суммарную нагрузку, но в статье это не указано. У нас на карту левел дизайнеры закидывали юнитов в какие-то точки уровня, чтобы имитировать хоть какую-то нагрузку, но это не обязательно, если есть общий тест боя.
А вот что действительно желательно это тест полного боя, причем так, чтобы сетевой код в нем тоже участвовал(какая-никакая, а тоже нагрузка на CPU). Тут два варианта:
1) Написать реплеи. Это делается не так уж сложно, хоть и кажется огромной задачей. Даже на кастомном движке. Гораздо сложнее их поддерживать, чем написать. Нам, например, пришлось писать отдельный декомпилятор в текстовый формат и компилятор обратно, для реплеев. Чтобы можно было подменять куски логики. В теории можно ввести версии реплеев, и научить игру саму проводить конвертацию к последней версии, но вот это уже выглядит как что-то долгое.
2) Написать скрипт имитирующий бой. И дальше либо пролет камеры через этот бой, либо "проход игрока". Тут главное, чтобы все было максимально честно на стороне клиента, и не пропускались обсчеты, которые происходили бы в случае сетевой игры.
Покушав как следует реплеев, я склоняюсь к тому, что скрипты все же удобнее. Но со скриптами дела имел мало, возможно не вижу каких-то подводных камней.
Плюс, что вам мешает запускать найтили тест перфы(даже хотя бы тот который у вас есть), и рисовать графики? Может вы это и делаете, но в статье про это ни слова. Хотя вроде как, тоже часть автоматизации перф тестов.
Ну и там всякие тесты скорости загрузки уровней, тесты адекватности коллизий(хотя это можно отнести к валидации), тесты на утечки памяти и тд.
Спешу огорчить, вы тестировали не производительность игры, как указано в заголовке, а производительность карты. Это, честно говоря, очень мало и достаточно печально.
Несколько человек потратили неделю, на то, что можно собрать одному за вечер? Серьезно?
И это имея книгу и туториалы...
Ну ладно, еще загрузку карт и ассетов сделали. Два вечера.
Два с половиной года.
Но справедливости ради, стоит сказать, что команда у них менялась от 40 до 75 человек. Думаю большинство подтянулось, когда пора было создавать контент.
Сколько точно у ребят, я не знаю :) Ну и тут, пока, только софтланч. Возможно года два до релиза и получится.
Обычно это так работает.
А попадание в пушку, на сколько я помню, всегда идет без урона. Плюс там маска оридия, все дела.