Юрий

Тоже пару лет назад изучал webgl, тоже было интересно (пригодилось один раз по мелочи, но не жалею ).

Поговаривают что WGL бесполезно изучать по исходникам других приложений и в этом есть доля правды. Хотя исходники пригодятся позже когда будете понимать основы.
learningwebgl мне в свое время помог, я выбрал путь изучать именно без библиотек - очень полезный опыт потом можно перенести и на десктопный openGL, хотя версии там более новые.

рекомендую такой путь.
идти по этим статьям - начинать именно с рендера треугольников - главное понять суть - как данные из js передать в видюху - как получить доступ к ним из шейдеров.

далее разобраться с матрицей трансформации - векторной арифметикой - посмотреть какие функции для векторов и матриц есть в шейдерном языке.
разобраться для чего нужны пикселные и вертексные шейдеры. Лично мне в этом плане очень сильно помогло чтение спецификации OpenGL ES 2.0 (гуглите в сети).

Когда поймете все эту кухню изнутри - можете выбирать библиотеку для работы с ним, потому что без библиотек работать очень тяжело - много повторяющегося кода (интерфейс очень низкоуровневый), реально писать только чтото очень простое, либо со временем заметите что свой фреймворк/библиотеку делаете.

В общем тема очень интересная - много всего увлекательного впереди, но изучать нужно реально много всего, параллельно с работой уйдут месяцы.

С библиотеками же по сути можно получать результат практически сразу - но если вы делаете чтото более менее типовое.

Надеюсь помог и желаю удачи!

если есть несколько вещей более значительных то не нужно, если нет - то пишите.

Инфы море на одном только хабре habrahabr.ru/search/?q=%5B%D0%B1%D0%BE%D1%82%5D&ta...

от себя добавлю что основные методы это
1) простейший понятный способ - поиск нужного элемента на экране и кликание по экрану, или клик по указанным координатам. я в основном использую этот способ, так как вмешательство в игру минимальное - ее не надо ломать, для онлайн игр - меньше шансов получить бан. Подходит для простых игр, в основном те что 2D пошаговые.
Гуглить отправку событий мыши и клавиатуры на выбранном вами ЯП (java robots например).
Минусы - игра должна быть постоянно открыта на экране и иметь фокус (можно решить - запустив игру с ботом в виртуалке).

2) для онлайн игр - изучение протокола обмена данными с сервером. нужно изучать куда отправляются/откуда получаются данные и в каком формате. пишем программу которая эмулирует клиент игры. очень хороший способ - для очень интерактивных игр - максимальная скорость. Способ довольно сложный надо реверсить протокол (гуглить wireshark) и возможно само приложение (гуглить дизассемблирование / декомпиляция). Если игра браузерная - то все может быть проще - запросы и ответы можно смотреть в консоли браузера. Очень перспективный способ - визуальный клиент не обязателен - можно делать армию ботов и размещать на серверах - скорее всего они будут потреблять немного памяти и процессора и возможности впечатляющие.

3) для десткопных игр - патчинг памяти запущенной игры. варианты от простых типа - поменять очки/деньги в игре (artmoney) это в основном для не онлайн игр, и до очень сложных - подменить адрес вызова системной функции - например функции отрисовки directx - то есть меняем адрес вызова на свою функци (недавно была серия статей на эту тему, к сожалению не нашел побыстрому). Либо как разновидность - декомпиляция игры - изменение логики - компиляция (гуглить все что связано с крекерством, создание кейгенов). Для этого варинта требуется довольно высокая квалификация, понимание того как работает игра. Также игры могут иметь защиту от этого.

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

Как наиболее мягко преодолеть этот барьер и успешно вылезти из комфорт-зоны?

постепенно создавать под ногами новый фундамент, не ломая старый.
другими словами не бросая работу использовать свободные ресурсы для создания новых активов - вкладывать время и деньги в знания и приобретать новые навыки, чтобы в случае чего была уверенность в завтрашнем дне. ("завтрашнее дно" - так по философски получилось)

помоему с заказчиком такое оговариваться должно.

то есть если технология популярная - исполнителей много - естественно ему проще найти человека который уже работал с ней.
если мало известная - то у него выбор или платить N в час человеку который еще изучать будет и время включено или заплатить 2 * N (грубо) человеку который сразу будет делать.

лучше отправлять токен вместо пары логин/пароль, из соображений безопасности. если ктото слушает трафик то пара логин пароль - дает ему доступ навсегда и отовсюду, в том числе может авторизоваться через веб интерфейс.

для получения токена пароль передается только один раз, его конечно тоже могут перехватить, но шансы меньше + для запроса авторизации можно использовать https

токен же действует ограниченное время и может не давать всех возможностей системы.

токен дает доступ только к апи. и например через апи злоумышленник не сможет сменить пароль пользователя. + токен удобен тем что может выдаваться на определенные права. например для одного токена есть доступ только к списку друзей пользователя, а через другой и к его личным сообщениям.

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

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

2) как уже заметили статик методы это зло. даже если вы используете классы и пишете на статиках все это совсем не ООП а обычный процедурный подход - те же самые функции. сам когда то таким болел.

Падает ли скорость от ORM?

скорость работы приложения может упасть, но все зависит еще и от того как написан код без ОРМ.

Падает ли скорость от ORM?

нет. скорость разработки может сильно возрасти, если уметь с ней работать.

лично мое мнение если проект изначально не хайлоад то лучше орм. скорость разарботки сильно увеличивается + код становится гораздо проще развивать и рефакторить. меньше ошибок - больше надежность, нет головной боли когда нужно чтото рефаткорить - проект развиается легко. если нагрузка возрастает - всегда есть много возможностей для оптимизации.

зачастую если нагрузка идет больше на чтение то надо кешировать + в узких местах, где требуется только показать чтото, можно делать прямые запросы к базе без орм. а орм использовать только для изменения обьектов.

хорошая орм не связывает руки а имеет возможности для тонкой работы на более низком уровне.

я использую пару лет doctrine2 для php, хотя до этого много лет писал запросы руками. возвращаться не хочу, хотя и могу.