Большое спасибо за статью! Я думаю тоже сделать игру на том же стеке - libgdx + Scala. Долго думал (альтернативы - Bevy или Fyrox, заодно подтянуть Rust, либо UE, чтоб минимум кода или совсем без).
Проблема только в том, что в разработке игр мой опыт около абсолютного нуля. С другой стороны, идея в плане графики не амбициозна. Но libgdx + Scala, кажется, верный для меня выбор. Спасибо ещё раз!
А если игра не realtime? В принципе, привязка изменения глобального состояния игры к очереди (или очередям) событий выглядит довольно логично. Для какого-нибудь пошагового кравлера или стратегии выглядит ок. Понятно, что для реалтайма большие накладные расходы и относительная непредсказуемость времени реакции будут неприемлемы (скорее всего).
Я вас уверяю, в других языках не меньше таких библиотек. И наиболее эффективные библиотеки написаны не на самом питоне. Преимущества питона - простота освоения и легкость написания небольших скриптов.
Хотите задачку? Попробуйте алгоритмы Брезенхема для плоскости, замощённой не квадратами, а шестиугольниками. Для прямых решение получилось интересное. А как для окружностей?
Преимущество Python тут в том, что весь процесс обработки данных и статистических расчетов я автоматизирую с помощью функций. Результатом выполнения кода будет сформированный Excel файл, где все расчеты красиво разложены по листам. В случае, если нужно добавить несколько пациентов или при обработке данных другого исследования, мне не нужно повторно заниматься всей этой работой. Это экономит для меня тонну времени. Хотя я уверен, что при виде моего кода, у программиста будет идти кровь из глаз (у меня у самого иногда так происходит при виде этого чудища).
Да, извините. Я сталкивался с такой ситуацией (причем работал с айтишниками - датасайентистами). Кровь из глаз - это был как раз тот эпитет, который я применил, увидев их код на питоне. Решение оказалось простым - DSL на базе даже не питона, а языка конфигурации. В итоге все были довольны - работа резко ускорилась, у меня больше кровь из глаз не шла, коллеги были счастливы, что все описания работы с данными стали читабельными. Думаю, что такого рода решения будут в будущем. Вам ведь тоже питон, в сущности, не нужен. Вам нужно обрабатывать данные. И инструментов для этого уже много. А программисты нужны, чтобы эти инструменты были. И не так уж много нас надо.
Ещё один пример того, что философов нельзя допускать до науки в наше время. Очень поверхностное и местами искаженное толкование.
"Чтоб был всегда доступен шмону
Отдельно взятый гегемон"
Клиенты, почему без биометрии? Без биометрии можно только там.
Большое спасибо за статью! Я думаю тоже сделать игру на том же стеке - libgdx + Scala. Долго думал (альтернативы - Bevy или Fyrox, заодно подтянуть Rust, либо UE, чтоб минимум кода или совсем без).
Проблема только в том, что в разработке игр мой опыт около абсолютного нуля. С другой стороны, идея в плане графики не амбициозна. Но libgdx + Scala, кажется, верный для меня выбор. Спасибо ещё раз!
Вот тот же вопрос, как разнообразие дистрибутивов влиет на работу на одном конкретно выбранном? Тем более самосборном?
Это как сказать, что вебразработка сдулась из-за обилия языков и фреймворков.
Такую логику очень удобно тестить из-за слабой связанности компонентов.
А если игра не realtime? В принципе, привязка изменения глобального состояния игры к очереди (или очередям) событий выглядит довольно логично. Для какого-нибудь пошагового кравлера или стратегии выглядит ок. Понятно, что для реалтайма большие накладные расходы и относительная непредсказуемость времени реакции будут неприемлемы (скорее всего).
Я рекомендую также взглянуть на scalacheck, возможно, подкинет дополнительные идеи. Там тестовый фреймворк с генерацией данных.
Плюс Японии в том, что в общем японский и не нужен, тебя всё равно постараются понять. Минус тот же.
Я сейчас пытаюсь японский по дуолинго, ну хоть словарный запас какой-то даёт. Корпоративные курсы - вообще полный ноль и путь в никуда.
А в чем заключается победа сони на рынке? Вроде нинтендо не остаёт. Или просто кликбейтный заголовок?
Я вас уверяю, в других языках не меньше таких библиотек. И наиболее эффективные библиотеки написаны не на самом питоне. Преимущества питона - простота освоения и легкость написания небольших скриптов.
Хотите задачку? Попробуйте алгоритмы Брезенхема для плоскости, замощённой не квадратами, а шестиугольниками. Для прямых решение получилось интересное. А как для окружностей?
Я бы предположил ещё фактор сравнивания. Люди сравнивают свою жизнь с другими и чувствуют себя менее счастливо, если живут хуже других.
А почему вы решили, что ошибка Хабра, а не почтового сервера, принявшего письмо и по каким-то причинам выплюнувшего Хабру отлуп?
Да, извините. Я сталкивался с такой ситуацией (причем работал с айтишниками - датасайентистами). Кровь из глаз - это был как раз тот эпитет, который я применил, увидев их код на питоне. Решение оказалось простым - DSL на базе даже не питона, а языка конфигурации. В итоге все были довольны - работа резко ускорилась, у меня больше кровь из глаз не шла, коллеги были счастливы, что все описания работы с данными стали читабельными. Думаю, что такого рода решения будут в будущем. Вам ведь тоже питон, в сущности, не нужен. Вам нужно обрабатывать данные. И инструментов для этого уже много. А программисты нужны, чтобы эти инструменты были. И не так уж много нас надо.
Ошибка компиляции в Scala :) Любое нецклевое использование: если нет рекурсии вообще или есть нехвостовая.
Для этого потребуется больше силовиков. Ну и для прочих нужд тоже.
Или даже немного вредить :)
Честно говоря, геймдев не особенно жалко. Учитывая, какое говнище в основном там пилится.
Задачи программистов имеют разную сложность. К какой области относятся вычисления выше? Крудошлепы, игроделы, большие данные?
PHP - DSL, пытающийся стать языком общего назначения. А зачем?