Search in topic

руководители кружков здесь есть?

Во-вторых - сейчас столько школоты и просто недоучек дорвались до юнити и прочих готовых инструментов, что количество корявых и бездарно прожирающих вычислительную мощность поделок бьёт все мыслимые пределы! И в том числе потому, что люди просто не знают, что означает тот или иной эффект, как он устроен, сколько памяти и тактов процессора он сжирает.

Это не только в игрописании, это везде так. Потому что сейчас проще, дешевле, и быстрей, воткнуть еще 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, мягкого реального времени распредленных и параллельных вычислений и … много чего еще ситуация саавсем другая. Люьми и их потребностями там и не пахнет. Программирование то не ограничивается задачей взаимодействие с чело

Конкретно про эрланг не скажу, не работал, но вообще ФЯПы не отличались быстродействием и я не уверен, насколько они подходят или не подходят для задач реального времени. Управление мотором, машиной или каким-нибудь там квадрокоптером - обычно на С\С++ пишется. Или на асме. Если только я чего-то не знаю 😃

Ну то есть свои родные самописные но те же кубики. А смысл? Чем выверенные стандартные не устраивают - или не знал потому написал свое с нуля… их десятки если не сотни со своими про и контра - но тем не менее массово свою радемую оконную библиотеку и виджеты для нее ни преподаватели ни программисты уже давно не пишут - бессмысленно

Скажу простую вещь, и вы навернйка найдёте в ней разумное зерно (из практики): частенько бывает, что стандартные библиотеки - слишком универсальны, от чего:

1. Жрут много памяти, даже если тебе нужна всего одна фича из всей библиотеки, а отключить лишнее нельзя - зависимости;
2. Сомнительное быстродействие. Если проблемы с быстродействием вылезли - оптимизация просто невозможна, кроме как в кишки лезть и пытаться там разобраться;
3. Иногда барьером является изучение. Сделать что-то простое и стандартное - очень просто, а шаг влево или вправо и всеръёз задумываешься, не быстрее и не проще было ли своё написать?

И в ряде случаев (не всегда, но далеко не редко!) оказывается, что выгоднее и проще именно своё решение написать строго под задачу: быстрое легковесное и простое.

Ну дык плохо заточенный нож это тот же уродский кубик - но ведь до правильной заточки ножа преподаватель кружка авиамоделирования не опускается.

Это что сейчас было?

Как раз наоборот - я на работу к себе не возьму умеющего “программировать в принципе”

Мы сейчас об обучении детей, или о проф подготовке?

Авиамодели - это же по сути тоже игрушки, мастерить можно и табуретки

Так то да. Но собрать ARF кит, и построить из говна и палок, это две большие разницы.

А табуретки, вы не видели табуреток созданных дизайнерами? Я про табуретки которые напоминют табуретки только внешне:-)

Это что сейчас было?

Вполне уместная аналогия.

Вот же ж любимый принцип:

Забавная механическая игрушка для детей. Не знаю, вышла ли в серию или нет, все видео с кикстартера…

Забавная механическая игрушка для детей.

Зачем это Здесь? Тут руководители кружков. Хватит зас…ть тему всякой лобудой!

зас…ть тему всякой лобудой!

К вопросу о процессе обучения детей, конечно.