руководители кружков здесь есть?
А сколько у вас выпущеных игр?
Выпущенных как коммерческое приложение для зарабатвания денег или написанных в процессе обучения детей и с активным участием. Первых за много лет тому назад 0 - я специализируюсь на M2M сервисах. Вторых в прошлом году штук 5.
Типичный состав команды для разработки игры:
Автор идеи игры программист и основной пользователь - 7 лет.
QA, CodeReview, Скин дизайнер (по бумажным эскизам автора) тех поддержка и менджер проекта (побуждающий делать а не отлынивать) - 50 лет
Платформа язык программирования и “кубики разработки” - Scratch
Все задуманные игрушки (не суть что они вариации на тему хорошо извесных аркад) благополучно автором/програамистом доведен до релиза. Отыграны авторами и его друзьями раза по три модифицированны и сейчас забыты как пройденный и теперь отлично понятный этап.
Для сравнения тот же “программист” в кружке по программированию на платформе PascalABC дальше вариаций на тему hello World не продвинулся как и все остальные изучающие программирование. Кружок к слову рассчитан на детей на пару тройку лет старше 7 летку туда взяли в качестве исключения за демонстрацию знаний по предмету.
И я надеюсь что мы все помним помним что говорим о тулсете не профессионалов создателях прорывов в гейм индустрии - те все давно знают чем как и каким образом им удобнее. И кубики пилить они умеют. Мы говорим об обучающем тулсете и о новичках и начинающих программистах изучающих вопрос как и на чем сегодня пишут игры.
И на сдачу сортируют пузырьком
Именно потому что новички пытаются в силу своего разумения пилить собственные “кубики сортировки” так как знают и умеют. А знают и умеют пока мало для того чтобы их пилить качественно. А используй они “готовый кубик” из стандартной библиотеки ну скажем - TreeSet и о чудо O(log(n)) даже при ооочень малых знаниях о алгоритмах сортировки и эффективности их применения. Ваш пример только подтверждает то что умение грамотно пользоваться “правильными кубиками” для результата важнее чем умение пилить их самостоятельно.
А уж освоив “стандартные хорошие кубики” не все но некоторые дойдут до состояния когда ЗНАЯ в каких условиях линейный поиск быстрее построения сбалансированного дерева сумеют осознанно запилить для конкретных условий и задач кубик более оптимальный чем в готовом наборе.
Во-вторых - сейчас столько школоты и просто недоучек дорвались до юнити и прочих готовых инструментов, что количество корявых и бездарно прожирающих вычислительную мощность поделок бьёт все мыслимые пределы! И в том числе потому, что люди просто не знают, что означает тот или иной эффект, как он устроен, сколько памяти и тактов процессора он сжирает.
Это не только в игрописании, это везде так. Потому что сейчас проще, дешевле, и быстрей, воткнуть еще 120 Гиг оперативки, и пару тройку десятков ядер к ним, вместо того чтобы нанять и содержать людей умеющих оптимизировать код вплоть до обработки кубиков напильником.
ЗЫ Как в известном анекдоте “…А в Париже есть не падшие женщины? Да, но их мало, и стоят они дорого.”
Картины можно лепить из клипартов, музыку из сэмплов, и это правильно:-)
Имя Энди Уорхол - что ни будь говорит в вопросе можно или нельзя?
Я грю про мелкопацанов, которые еще толком не понимают чего хотят.
Вот и я говорю про них. Чему именно они хотят научится и получить как результат - самолет или умение пилить напильником .
У мя пацаны пишут Г-код напрямую, в текстовом редакторе, под это дело.
Дык я тоже WSDL, swagger пишу и читаю что в нем что в vi без проблем - но SOAP UI для новичка все равно лучше 😃.
Дык я тоже WSDL, swagger пишу и читаю что в нем что в vi без проблем - но SOAP UI для новичка все равно лучше .
Не в редакторе под это дело, а код под это дело:-)
Платформа язык программирования и “кубики разработки” - Scratch
Рассказать что там в нутре этих полиморфных кубиков? И как красиво они пилятся напильником. И почему они не прижились?
(прошу простить за частичный оффтоп)
Выпущенных как коммерческое приложение для зарабатвания денег или написанных в процессе обучения детей и с активным участием. Первых за много лет тому назад 0 - я специализируюсь на M2M сервисах. Вторых в прошлом году штук 5.
1 и 2 - существенно разный уровень требований касаемо степени допилки. При выходе на рынок (деньги - это всегда третье дело, так как они возможны ТОЛЬКО после успеха) продукт должен быть не ниже некой незримой “планки качества”: если выше - получает распространение и может быть комерциализирован, если ниже - сразу нуль: не нужен вообще никому, так как рядом полно более привлекательных аналогов.
Для детей и процесса обучения требования не высоки: по большому счёту дети на занятии будут “играть” во что угодно, что дадут.
Разница в трудоёмкости между 1 и 2 - около 90%. Эти самые 90% - это полировка и допилка; то, что отличает коммерческий продукт от играбельной бетты.
К настоящему моменту шесть выпущеных коммерческих игр. Полная разработка, кроме музыки. И еще около десятка при работе на фирму (там были отдельные художники).
Типичный состав команды для разработки игры:
Это вы наверное какой-то свой случай описываете. А в жизни - состав команды очень зависит от “размеров” игры. В мелких инди-командах зачастую не более 3х человек: два программера и один художник. Звукач\музыкант - либо кто-то из них по совместительству, или приглашённый\нанятый. Или звуки-музыка тупо лицензируются с какого-нибудь audiojungle.
благополучно автором/програамистом доведен до релиза. Отыграны авторами и его друзьями раза по три модифицированны и сейчас забыты как пройденный и теперь отлично понятный этап.
Звучит несколько наивно, поясню:
- Нельзя нормально протестировать игру на друзья\родственниках. Ценность обратной связи от них - нуль, а иногда даже вред. Вред - это когда друзья и родственники начинают советовать, а разработчик - эти советы слушать.
А самое главное - не сунувшись на рынок, где конкуренция коммерческих продуктов, нельзя ощутить реальный объем работы, нельзя научиться смотреть сквозь характеристики своего продукта и его недостатки: понимать до мелочей, что там правильно, что не правильно, что работает (как игровая механика), а что нет. Не ощутить те 90% титанической работы, которые являются обязательным условием для превращения бетты в законченый конкурентоспособный продукт. И вот эти вещи они никак не связаны ни с технологией (самодельное оно с нуля или на юнити из готовых ассетов), ни с умением писать оптимальный код. И никак не связаны с умением придумать что-то оригинальное или новое. Это тонкости из области продукт-дизайна, гейм-дизайна, наративного дизайна и психологии.
Для сравнения тот же “программист” в кружке по программированию на платформе PascalABC дальше вариаций на тему hello World не продвинулся как и все остальные изуча…
Это зависит от преподавателя, а не от платформы. Думаю, вы прекрасно это понимаете 😃
…Мы говорим об обучающем тулсете и о новичках и начинающих программистах изучающих вопрос как и на чем сегодня пишут игры.
К вопросу как и на чём: тут важно не путать средства разработки по степени их популярности и раскрученности - с применимостью самих технологий. До сих пор игры делают на всём, что можно заставить инерактивную картинку на экран вывести. Можно на MS excel игру сделать и на маткаде тоже можно.
Именно потому что новички пытаются в силу своего разумения пилить собственные “кубики сортировки” так как знают и умеют. А знают и умеют пока мало для того чтобы их пилить качественно.
- Без вот такого пиления они точно знать и уметь нифига не будут. В том числе:
и о чудо O(log(n))
- будут элементарно не знать, что такое вычислительная сложность.
Ваш пример только подтверждает то что умение грамотно пользоваться “правильными кубиками” для результата важнее чем умение пилить их само…
В корне не согласен!
Ключевым является не “использовать правильные (?) кубики”, а “уметь пользоваться выбранным инструментом”!
А еще лучше - уметь пользоваться разными инструментами.
А уж освоив “стандартные хорошие кубики” не все но некоторые дойдут до состояния когда…
Повторюсь: нет “стандартных хороших кубиков”. Есть популярные. Юнити - популярен. Но так ли он хорош? Ведь, чисто как пример, буквально рядом с ним в индустрие - популярны такие уродливые чудища, как яваскрипт и ПХП 😵 Популярное != хорошее.
Если преподавать программирование детям - глубоко убеждён, что надо преподавать классику: плюсы, может быть паскаль. Опционально - шарп или яву.
Напоследок: вот человек, тоже реальный разработчик с опытом коммерческих игр, рассказывает свой опыт ведения детского кружка по программированию игр. Думаю, это интересный материал: flashgameblogs.ru/blog/results/1619.html
Рассказать что там в нутре
Вы точно о Scratch и процессе создания игр и обучения основам програмирования на его основе - или о им подобным “Lego - кубикам” програмирования. CodeCombat, JavaRush, Алиса.
На счет - не прижились. В процессах обучения (увы не в Российских школьно кружковых реалиях) еще как прижились. Когда ребенок в CodeCombat (Python) потратив день писхуя ругаясь что ничего не получается через день вечером радостно и гордо сообщает "Папа я понял в чем дело. Я переменную не в том цикле проверяю по этом он неправильно дерется " - поверьте это много стоит в плане ОБУЧЕНИЯ программированию. И то что программирование в CodeCombat даже и на языке Python в общем то “ненастоящее” и “игрушечное” программирование кубиками в плане ОБУЧЕНИЯ навыку думать понимать какие кубики есть и что они обеспечивают искать проблему и решать ее используя тот тул сет что есть совершенно не важно.
Это вы наверное какой-то свой случай описываете.
Естствено это случай когда я обучаю навыкам программирования ребенка задавшего вопрос а можно написать вот такую игру.
Это старт с нуля и введение в профессию/увлечение. А не выращивание эффективной производственной команды. Строительство “завода” ведется совершенно по другим лекалам - но на конвеерную линию завода и не полный ноль приходит ноль идет в ПТУ.
Не ощутить те 90% титанической работы,
А новичку пробующему свои силы и еще не понимающего нравится ему это направление или нет в принципе это НАДО? ощущать эти 90% титанической работы?
Ну вот честно - что для ребенка начинающего обучение в авиамодельном кружке привлекательнее и на занятия какого кружка он пойдет с большим удовольствием
– туда где начинают со сборки самолета из готовых вырезанных деталей а потом учат их вырезать правильно держа нож
– или туда где начинают с обучения как правильно держать нож а до сборки самолета допускают избранных кто наконец то смог вырезать правильные детали
Вот IMHO ключевое в обучении
— По вашей ссылке
Стараюсь следовать правилу: после очередного занятия у каждого ученика должна появиться новая фишка и проект должен быть рабочим на конец урока
—
И для достижения этой цели все средства хороши. ЕСли квалификация и опыт обучающегося требует выдачи Lego кубиков - надо выдавать кубики.
Для обучающегося важно не понять трудности настоящей разработки, не освоить правильный язык - но привыкнуть в заданное время и регулярно получить результат. Остальное включая навыки правильного использования правильного инструмента со времени появится как инструмент и способ достижения этой цели.
Если преподавать программирование детям - глубоко убеждён, что надо преподавать классику: плюсы, может быть паскаль. Опционально - шарп или яву.
А я глубоко убежден что детям не нужен ни Паскаль, ни C# ни java. Важнее навык структурного мышления, знание назначения инструментов тулсета и умение корректно и по назначению их использовать. Знание как устроены эти инструменты внутри - полезно но не критично и играет заметную роль в достаточно редких ситуация. А вот не знание назначения, возможностей и ограничений “кубиков” и попытка заменить их своим разумением исходя из общих принципов “играет сразу” с грохотом и треском.
Forth, Fortran, Occam, C, C++, Pascal, Basic ( в разных различных и разнообразных вариация от GW до Visual), PHP, Python, Erlang, Java, Bash - языки и платформы чтение и выражение мыслей на которых у меня не вызывает затруднений (экзотические или специализированные варианты типа PlayBook Ansible и иже с ними оставим за скобками). Но действительно эффективно я могу работать только на тех платформах и языках чьи “кубики лего” висят на кончиках пальцев. Собрать надежный Web сервис быстрее качественнее и правильнее мне на основе готового Lego-кубика на выбор - JAX_WS, AXIS2, CXF несмотря на то что знание позволяет его пилить и на С и на Bash скрипте (и такое было по необходимости).
И еще пример важности знания кубиков, а не языка или инструмента.
Навыки программирования общего вида на Java слабо помогают пониманию как работает код RabbitMQ (Erlang). А вот знание “лего кубика” - лмбда исчисления и замыкания - с чем их едят и как применяется очень даже. И неважно где именно освоен кубик и его принципы в Erlang (как основа языка) или в Java (как специфическая возможность одной из версий).
Вы точно о Scratch
Я про scratch.mit.edu . Проект замечательный, ток его цель (одна из) как раз популяризация того лучшего что не прижилось.
Эк тут народ понесло…
И котлеты и мухи в кучу.
Техническое творчество (моделизм) - в основе имеет цель научить думать головой и работать руками с материалами и инструментом для достижения определенной цели.
Все остальные направления так или иначе исключают материалы и инструмент. Работа руками и получение результата сводится к манипуляциям с “кубиками”.
С задачами преподавателя - всё еще хуже… Как оценить работу преподавателя в творчестве (пусть и техническом), если критерии оценки привязаны к результатам типа массовости участия в мероприятиях, количеству грамот и призовых мест?
Если всё это поделить на неоднородность в уровне подготовки, восприятия и кривизны рук детей, помножить на нулевое финансирование и мизерные зарплаты педагогов - то станет понятно, почему лучше сделать много примитивов, чем упираться и достигать реально интересных результатов.
Это старт с нуля и введение в профессию/увлечение. А не выращивание эффективной производственной команды.
Да, извиняюсь, немного про другое говорил. Ребёнку, безусловно, не надо сразу профессионально.
Вот IMHO ключевое в обучении
— По вашей ссылке
Стараюсь следовать правилу: после очередного занятия у каждого ученика должна появиться новая фишка и проект должен быть рабочим на конец урока
Так это не ИМХО не какое, это самое важное!!! Результат - это то, что заставляет людей (и особенно детей) продолжать заниматься чем-то.
Но при этом:
Для обучающегося важно не понять трудности настоящей разработки, не освоить правильный язык - но привыкнуть в заданное время и регулярно получить результат. Остальное включая навыки правильного использования правильного инструмента со време.
С одной стороны, безусловно, нет особой разницы, какие кубики. С другой - некоторые кубики бывают откровенно уродскими и могут научить плохому; другие - быстро органичивают обучающегося и в итоге тоже могут научить плохому (допустим классические варианты бейсика, в котором нет структур и классов и где допустим нельзя функции именовать).
А я глубоко убежден что детям не нужен ни Паскаль, ни C# ни java. Важнее навык структурного мышления, знание назначения инструментов тулсета и умение корректно и по назна…
- Если преподаватель не лентяй, то можно хоть на васике, хоть на пасрале сделать заготовки (вплоть до фрэймвёрков), где у ребёнка на экране уже будет все двигаться и шевелиться, а нало лишь менять кое-какие параметры и дописывать минимальный код, без необходимости писать всё с нуля.
Да и всякие обучающие среды и обёртки для детей, типа вашего Scratch, придуманы не вчера: c-robots и p-robots были еще в 80х годах, а еще раньше был Logo (хотя сам лично я этого не успел застать - для меня это просто история).
Навыки программирования общего вида на Java слабо помогают пониманию как работает код RabbitMQ (Erlang)
ИМХО функциональное программирование не является практичным и его вообще изучать не обязательно, кроме как для расширения кругозора. Даже несмотря на попытки из года в год дотянуть функциональные языки до применения в коммерческой разработке! Просто потому, что покуда программа взаимодействует с человеком - она должна подстраиваться под человека. А человек не мыслит функциями, он мыслит последовательным изменением состояний, как машина Тьюринга. В итоге код на ФЯП в той или иной мере по структуре становится похожим на обычный ЯП: где заведены переменные и производятся их последовательные преобразования. Чистых функциональных языков нет, они почти все мультипарадигменные. А для обычных ЯП, типа упомянутой явы, лямбды - не более, чам синтаксический сахар, нужды в них нет. И даже больше того: чем гибче язык и чем больше в нём всего - тем больше на этом самом языке в итоге го8нокода. Это правда жизни. С этой точки зрения есть большой смысл обучать на чём-то простом или строгом, без буйства парадигм и возможностей.
Напоследок: вот человек, тоже реальный разработчик с опытом коммерческих игр, рассказывает свой опыт ведения детского кружка по программированию игр.
Опять узкая специализация. ИМХО Учить нужно программировать в принципе, а не конкретному языку/фреймворку/здаче.
А так, те же кубики, вид с боку.
Опять узкая специализация.
Совсем не узкая. Из всего программирования, разработка игр - включает в себя больше число разных задлач, в том числе программных. Почти все современные наработки в области ИИ, например, выросли из игр или на играх.
Ну а для детей - это просто хорошая мотивация, простой способ получить осязаемый результат!
Авиамодели - это же по сути тоже игрушки, мастерить можно и табуретки 😃
С другой - некоторые кубики бывают откровенно уродскими
Ну дык плохо заточенный нож это тот же уродский кубик - но ведь до правильной заточки ножа преподаватель кружка авиамоделирования не опускается. Хотя это тоже весьма неплохое умение точить ножи до бритвенной остроты. Рекомендованный нож априори предполагается правильным и острым - аналогично рекомендуемый Lego-кубик не уродским а правильным для задачи. Тупые ножи и идиотские кубики естественно существуют - их брать не надо.
другие - быстро органичивают обучающегося и в итоге тоже могут научить плохому
Тут тоже преподавателю все козыри в руки. Одна из задач преподавателя научить детей вовремя понимать что тулсет/инструмент отлично подходящий под задачи и цели одного этапа/тип задач может совершенно не подходит под цели и задачи другого этапа и при переходе к нему пора осваивать новые инструменты и кубики. Вовремя понять и что освоенное устарело или просто не подходит под задачу, выбрать, освоить и применить более адекватное задаче инструменты - великое и ценное умение. Порой оно даже важнее виртуозного владения чем то конкретным. При этом метаться лишний раз тоже вредно. Тут главное не попасть в ситуации - когда в руках молоток все задачи становятся похожими на гвозди или по ходу проекта сумел освоить 10 технологий но проект так и не завершил.
Просто потому, что покуда программа взаимодействует с человеком - она должна подстраиваться под человека.
А Erlang не для человека. Пилить GUI на Erlang-е мазозхизм. А вот с нише M2M, мягкого реального времени распредленных и параллельных вычислений и … много чего еще ситуация саавсем другая. Люьми и их потребностями там и не пахнет. Программирование то не ограничивается задачей взаимодействие с человеком. Надеюсь для всех давно не секрет что 99% промышленных программ, компьютеров и систем о существовании человека о необходимости и проблемах взаимодействия с ним даже не догадываются. Самый яркий пример - мозги автомобиля, их миллионы - а софта отвечающий за взаимодействие с человеком в них дай бог процент наберется. Угол опережения, показания лямбда зонда, датчика детонации, … 100500 датчиков его интересуют, им обслуживаются и занимают 90% его внимания и объема кода. А вопросы какую зажечь лампочку или что нарисовать на экране им решаются по остаточному принципу в свободное от основной работы время . В мире профессионального программирования - “убить человеков вся власть роботам” IMHO давно свершившийся факт. НУ по крайне мере за последние лет 8 я написал сотни если тысячи машинных интерфейсов и методов и дай бог пар тройку GUI взаимодействия с человеком.
если преподаватель не лентяй,… сделать заготовки (вплоть до фрэймвёрков)
Ну то есть свои родные самописные но те же кубики. А смысл? Чем выверенные стандартные не устраивают - или не знал потому написал свое с нуля.
Кто из нас в детстве не писал собственную библиотеку создания и управления оконным интефейсом - в детстве (года 80-90) писали почитай все - а сейчас за исключением ооооочень малой прослойки почему то при построении GUI пользуются той или иной готовой профессиональной или не очень библиотекой не изобретая в 100500 раз велосипед. Кто QT, кто MFC, кто Swing, кто … их десятки если не сотни со своими про и контра - но тем не менее массово свою радемую оконную библиотеку и виджеты для нее ни преподаватели ни программисты уже давно не пишут - бессмысленно. Готовых кубико-конструкторов UI достаточно чтобы не определять в своей Windows программе оконную функцию и цикл обработки событий окна - нынешние программисты и слов то таких не знают - они и правильно.
ИМХО Учить нужно программировать в принципе
Как раз наоборот - я на работу к себе не возьму умеющего “программировать в принципе” но не знающий ключевых для моей отрасли и систем библиотек, реализаций протоколов, фреймоворков разработки и т.д. и т.п. Пробелы и незнание отдельных аспектов можно пропустить ибо абсолютно все знать невозможно а научится можно чему угодно - но если человеку при приеме на работу надо учится всему - я же на работу в отдел принимаю человека а не на учебу.
Ну зачем мне человек без знаний и опыта работы с JMS, Web-серверами, знания XML и стека работы с ним, понимания деталей работы протоколов HTTP, OAUTH2, механизма работы инжекции зависимостей, общей структуры и ключевых элементов IT ландшафта оператора связи или вообще путающий Java и JavaScript.
Вот когда освоить базовые для отрасли и нашего отдела навыки и знания - welcome 100+ без проблем. “А без елочки не приходи”.
Во блин. Прям как на форум программистов заглянул. 😦
Во блин. Прям как на форум программистов заглянул.
Некоторые больше “рыбаков” напоминают, с указанием длины рыбы…😃
И главное на один глагол, жгут “десятком”.😒
Во блин. Прям как на форум программистов заглянул. 😦
- Так это в свете обучения детей! А обучать программированию, между прочим - неплохая вещь. Не требуется мастерская, не нужно сложное оборудование - в этом плюс!
Конечно это НЕ замена техническим кружкам, где руками надо физически мастерить, но может быть неплохим дополнением.
А Erlang не для человека. Пилить GUI на Erlang-е мазозхизм. А вот с нише M2M, мягкого реального времени распредленных и параллельных вычислений и … много чего еще ситуация саавсем другая. Люьми и их потребностями там и не пахнет. Программирование то не ограничивается задачей взаимодействие с чело
Конкретно про эрланг не скажу, не работал, но вообще ФЯПы не отличались быстродействием и я не уверен, насколько они подходят или не подходят для задач реального времени. Управление мотором, машиной или каким-нибудь там квадрокоптером - обычно на С\С++ пишется. Или на асме. Если только я чего-то не знаю 😃
Ну то есть свои родные самописные но те же кубики. А смысл? Чем выверенные стандартные не устраивают - или не знал потому написал свое с нуля… их десятки если не сотни со своими про и контра - но тем не менее массово свою радемую оконную библиотеку и виджеты для нее ни преподаватели ни программисты уже давно не пишут - бессмысленно
Скажу простую вещь, и вы навернйка найдёте в ней разумное зерно (из практики): частенько бывает, что стандартные библиотеки - слишком универсальны, от чего:
- Жрут много памяти, даже если тебе нужна всего одна фича из всей библиотеки, а отключить лишнее нельзя - зависимости;
- Сомнительное быстродействие. Если проблемы с быстродействием вылезли - оптимизация просто невозможна, кроме как в кишки лезть и пытаться там разобраться;
- Иногда барьером является изучение. Сделать что-то простое и стандартное - очень просто, а шаг влево или вправо и всеръёз задумываешься, не быстрее и не проще было ли своё написать?
И в ряде случаев (не всегда, но далеко не редко!) оказывается, что выгоднее и проще именно своё решение написать строго под задачу: быстрое легковесное и простое.
Ну дык плохо заточенный нож это тот же уродский кубик - но ведь до правильной заточки ножа преподаватель кружка авиамоделирования не опускается.
Это что сейчас было?
Как раз наоборот - я на работу к себе не возьму умеющего “программировать в принципе”
Мы сейчас об обучении детей, или о проф подготовке?
Авиамодели - это же по сути тоже игрушки, мастерить можно и табуретки
Так то да. Но собрать ARF кит, и построить из говна и палок, это две большие разницы.
А табуретки, вы не видели табуреток созданных дизайнерами? Я про табуретки которые напоминют табуретки только внешне:-)
Это что сейчас было?
Вполне уместная аналогия.
Вот же ж любимый принцип:
Забавная механическая игрушка для детей. Не знаю, вышла ли в серию или нет, все видео с кикстартера…
Забавная механическая игрушка для детей.
Зачем это Здесь? Тут руководители кружков. Хватит зас…ть тему всякой лобудой!