На JS не пишу, но иногда бывает. ИМХО, заголовок статьи не удачный. Внимание цепляет, но содержанию не совсем соответствует. Разбираем тестовое задание для джуна - вот это более в тему. Начало мне понравилось, когда пошел код не совсем. Захождение в профиль для просмотра статей выглядит как попытка надавить авторитетом.
Они первые начали использовать именно программируемые картриджи, сама идея сменных носителей для игр была уже использована в Magnavox Odyssey.
+ Хотелось бы узнать, каков был размер команды, над который был поставлен главным инженером Лоусон. Дело в том что некоторые думают, что Стив джобс - изобрел Айфон. А сделала это команда инженеров Apple.
Если проект на 2-3 месяца, а исполнитель делает его пол года. Это я называю провал сроков. Аналогичный проект делался 2 месяца другим исполнителем. Ни каких подводных камней не всплывало, т.е. не было причин так долго делать. А в статье, которую вы указали, сроки срывались максимум на 10 дней, это я даже срывом сроков назвать не могу=)
6 лет ищем разработчика. За это время поработало 3 человека. Первый уволился через 2 месяца работы, второй проработал почти год так и не смог научится укладываться в сроки и был уволен. Последний уехал в мск на более высокую зарплату и столичную тусовку. Мы все еще ищем разработчика (игр). Приходили к нам и люди без опыта (т.е. совсем, с желанием войти в IT) и студенты которые прилежно отсидели 4-6лет в универе. Были и люди с курсов. И ты смотришь на человека и понимаешь, что с ним надо будет, как с маленьким ребенком, минимум год - ходить и показывать/учить как и что работает. Потому что самостоятельности ноль! А это деньги. которые и сам можешь заработать, а не тратить время на этого человека, который через год помашает ручкой, т.к. получил более выгодное предложение.
Мной написаны различные модули. Ни один не пригодился в чистом виде, так так все мои проекты в разных жанрах. Больше модули не пишу. Если вы пилите карточные/матч3 игры и у вас получается эффективно переиспользовать код, я за вас очень рад. Но не во всех ситуациях стоит так делать. Вот эту мысль я пытаюсь донести. Причем в арсенале команды есть свой фреймворк. Но игровые модули туда не входят.
Так я ж не против отделения логики от отображения. Я против универсального кода. Для примера, за 6 лет работы с HAXE вышло две новых версии языка 3 и 4 (не беру в расчет промежуточные). И я не могу оставить приложения на старых версиях, по тому что для мобильных сторов, мне нужны новые фичи языка. Я не хочу обновлять графичексую часть - мне нужно обновить только логику. Но с новой версией языка, я должен лезть в графическую часть, потому что там что то отвалилось((( С Unity примерно та же самая беда. Люди заказывали портирование игр с Unity на что угодно, потому что обновить старые проекты до новой версии движка очень больно.
Работаю с OpenFL и Haxe, и могу сказать что кроссплатформенность имеет свои плюсы и минусы. И не было ни одного проекта, где не приходилось бы решать какие то проблемы, после компиляции на требуемые платформы. А проблемы связаны обычно с требованиями или ограничениями платформы. Лет 10 назад мне тоже казалось, что повторное использование кода это круто. Жизнь показала, что уже через пару лет код протухает. Выходят новые версии языков\движков\e.t.c. и лучше выходит написать свежий код который отвечает новым требованиям. Сыровата статья. Много выделений жирным.
Простите, но я чего то не понял про маскировку. Мне интересно, что было у разработчиков в инструментах. И какова была аргументация изменения рабочего пайплайна.
Статью прочитал. Немного сумбурно, переход от мидкора к гиперказуалкам был неожиданным.
На JS не пишу, но иногда бывает.
ИМХО, заголовок статьи не удачный. Внимание цепляет, но содержанию не совсем соответствует. Разбираем тестовое задание для джуна - вот это более в тему. Начало мне понравилось, когда пошел код не совсем.
Захождение в профиль для просмотра статей выглядит как попытка надавить авторитетом.
Они первые начали использовать именно программируемые картриджи, сама идея сменных носителей для игр была уже использована в Magnavox Odyssey.
+ Хотелось бы узнать, каков был размер команды, над который был поставлен главным инженером Лоусон. Дело в том что некоторые думают, что Стив джобс - изобрел Айфон. А сделала это команда инженеров Apple.
"Fairchild Channel F — вторая в мире игровая приставка со сменными играми на картриджах ..."
статья в википедии
Если проект на 2-3 месяца, а исполнитель делает его пол года. Это я называю провал сроков. Аналогичный проект делался 2 месяца другим исполнителем. Ни каких подводных камней не всплывало, т.е. не было причин так долго делать. А в статье, которую вы указали, сроки срывались максимум на 10 дней, это я даже срывом сроков назвать не могу=)
6 лет ищем разработчика. За это время поработало 3 человека. Первый уволился через 2 месяца работы, второй проработал почти год так и не смог научится укладываться в сроки и был уволен. Последний уехал в мск на более высокую зарплату и столичную тусовку.
Мы все еще ищем разработчика (игр). Приходили к нам и люди без опыта (т.е. совсем, с желанием войти в IT) и студенты которые прилежно отсидели 4-6лет в универе.
Были и люди с курсов. И ты смотришь на человека и понимаешь, что с ним надо будет, как с маленьким ребенком, минимум год - ходить и показывать/учить как и что работает. Потому что самостоятельности ноль! А это деньги. которые и сам можешь заработать, а не тратить время на этого человека, который через год помашает ручкой, т.к. получил более выгодное предложение.
Совершенно с вами согласен.
Как же я вас понимаю...
Мной написаны различные модули. Ни один не пригодился в чистом виде, так так все мои проекты в разных жанрах. Больше модули не пишу. Если вы пилите карточные/матч3 игры и у вас получается эффективно переиспользовать код, я за вас очень рад. Но не во всех ситуациях стоит так делать. Вот эту мысль я пытаюсь донести.
Причем в арсенале команды есть свой фреймворк. Но игровые модули туда не входят.
Тоже запускал ваше творчество)))
Так а кем все таки стали, чем на жизнь зарабатываете? На канал подписался, дома посмотрю.
Так я ж не против отделения логики от отображения. Я против универсального кода. Для примера, за 6 лет работы с HAXE вышло две новых версии языка 3 и 4 (не беру в расчет промежуточные). И я не могу оставить приложения на старых версиях, по тому что для мобильных сторов, мне нужны новые фичи языка. Я не хочу обновлять графичексую часть - мне нужно обновить только логику. Но с новой версией языка, я должен лезть в графическую часть, потому что там что то отвалилось(((
С Unity примерно та же самая беда. Люди заказывали портирование игр с Unity на что угодно, потому что обновить старые проекты до новой версии движка очень больно.
Работаю с OpenFL и Haxe, и могу сказать что кроссплатформенность имеет свои плюсы и минусы. И не было ни одного проекта, где не приходилось бы решать какие то проблемы, после компиляции на требуемые платформы. А проблемы связаны обычно с требованиями или ограничениями платформы.
Лет 10 назад мне тоже казалось, что повторное использование кода это круто. Жизнь показала, что уже через пару лет код протухает. Выходят новые версии языков\движков\e.t.c. и лучше выходит написать свежий код который отвечает новым требованиям.
Сыровата статья. Много выделений жирным.
Очень много жирного шрифта, не возможно читать.
+1
Так а что в итоге с движком?
Хотелось движок, а сделали библиотеку? Может не правильно выразились?
Простите, но я чего то не понял про маскировку. Мне интересно, что было у разработчиков в инструментах. И какова была аргументация изменения рабочего пайплайна.
Распишите, пожалуйста, что именно за практики были у команд. Какой подход преобладал.
Держитесь!