Я бы не сказал, что какой-то из этих языков учится принципиально быстрее или медленнее других. Опытный разработчик освоит любой из них за примерно равное время. Для новичков уместно говорить скорее не о скорости обучения, а о пороге входа (т.е. времени, за который можно написать минимальное действующее приложение), в этом плане явно лидирует PHP и JavaScript. Потом Python c Ruby. Потом C# (это, конечно, субъективно очень).
По наличию инструментов, для Python, PHP, Ruby есть отличные фреймворки, они явно ускорят работу. Для JavaScript (NodeJS) скорее всего стабильных фреймворков пока нет (не в курсе), о C# в вебе вообще ничего не знаю, но проприетарность платформы я бы записал в минус.
С простотой обслуживания примерно та же ситуация как и с обучением. Знающий ЯП и используемые библиотеки человек будет поддерживать код эффективно, не знающий будет тормозить. Острее вопрос с поиском специалистов. На сколько я знаю, PHP-шников на рынке чуть ли не больше, чем всех остальных вместе взятых. Хотя средний уровень их ниже, но для небольших и средних проектов искать разработчиков на PHP будет заметно проще. Для больших же проектов имеет смысл делать выбор под уже имеющуюся команду.
Про концепты можно долго философствовать, это во многом субъективно, конечно.
Для примера, в Python на порядок удобнее метапрограммирование (например, чем в C), благодаря этому в Django реализована отличная и простая orm с описанием схемы базы на самом ЯП.
В том же Python декораторы хорошо вписываются в концепцию обработки http-запросов вьюшками, позволяя удобным способом навешивать на них дополнительный функционал.
Под взаимодействием я имел в виду в первую очередь «тип игры»: у пошаговой стратегии и шутера разные модели взаимодействия с сервером :-)
С 2к пиком никакие отдельные серверы авторизации не понадобятся. Делайте монолитную архитектуру с заделом на выделение отдельных компонентов. То есть просто следите, что бы лишних зависимостей не возникало. Если вдруг понадобится что-то вынести в отдельный сервис — это сразу станет понятно.
Такой подход позволит с большей веротяностью закончить проект (с минимумом усилий). Если самая-главная цель — выучиться, то тут всё совсем просто: хотите разобраться с сервером авторизации — разбираетесь, не хотите — не разбирайтесь.
Так же отмечу, что пик в 100 онлайна — уже успех. 2к — сложно достигнуть.
Каким образом реализовать — читайте доки, импортируете модуль, настраиваете и вперёд.
В скобках может быть python style выражение арифметическими, логическими операторами и так далее. Плюс, в шаблонизаторе есть циклы, макросы, импорт других шаблонов, наследования шаблонов.
Добавление функционала осуществляется реализацией глобальных функций (rand в Вашем случае) — просто указываете, что такая-то функиця вызывается таким-то именем.
Так же есть возможность реализации фильтров, что-то вроде {{value|filter_x|round|abs}}, которые поочерёдно преобразуют значение.
Владислав Орлов
1. Совсем странная мысль. Во-первых сейчас мало что действительно интерпретируется. Во-вторых, разграничение на рантайм/интрепретацию, мягко говоря, странное и необоснованное. Рантайм — это когда программа выполняется, а как — это уже совершенно другой вопрос. Ничто не мешает подгружать данные и в других языках. Только это не решение всех проблем, а частный случай. Существенного выигрыша по памяти всё равно не будет.
3. Знание алгоритмов и таких понятий как вычислительная сложность слабо коррелирует со знанием ЯП. Это одно из очень популярных заблуждений C++ программистов, от него надо избавляться.
Как сказали в предыдущем комментарии, 500-ая ошибка означает что было вызвано исключение. Для него должен был быть доступен stacktrace и некоторая другая информация. При включённом режиме отладки он вернулся бы в теле запроса. При выключеном, должен придти на почту админам (если проект правильно сконфигурирован).
1) Вы действительно надеетесь продержать мотивацию всё время обучения, работая над чужой идеей? У большинства мотивации на свои идеи не хватает.
2) Если целью является разработка игр — идите работать, составьте за пару лет представление о предметной области, наберитесь опыта и потом объективно выбирайте тему для магистерской.
Без представления о предметной области Вы за время обучения в лучшем случае сделаете добротный велосипед с почти круглыми колёсами. Этот велосипед, в итоге, не понадобится ни сообществу ни Вам.
Чужие идеи помогут, если вопрос встанет в следующем виде: «я интересуюсь геймдевом, конкретно, областями 1, 2 и 3. На сколько я знаю, в этих областях есть нерешённые проблемы А, Б, В, Г и Д. Какую из них (или из схожих проблем) можно попытаться решить за время обучения в магистратуре? Какие компании могут заинтересоваться моими исследованиями?»
Дополню по ИИ, как человек имеющий профильное образование.
Академический ИИ имеет крайне слабую связь с игровым ИИ. Для занятия игровым ИИ нужен руководитель из индустрии, имеющий опыт разработки ИИ для ААА игр. Таких людей не больше сотни на планете наберётся.
Конечно, это в случае серьёзного занятия серьёзными ИИ. Для убийства времени любая тема сгодится.
Судя по формулировке вопроса, для Вас это ещё совсем неизвестная область, поэтому очень рекомендую написать прототип как получается. По итогам разработки прототипа многое само собой станет ясно и можно будет начинать реальную разработку. При этому полезно отдельно выделить бизнес-логику, чтобы её можно было легко перенести дальше.
По БД: для разных данных нужны разные подходы, может оказаться, что нужно несколько разных.
Кэширование не сводится к чему-то конкретному, оно может понадобится в совершенно любом месте, нужно всегда быть готовым к этому.
@victorvsk мельком посмотрел книгу, выглядит годно, на досуге почитаю. Большое спасибо.
По поводу устаревания не согласен. Это смотря что формализировать, если какие-то низкоуровневые фичи, до конечно устареют. А если то, что надо, то не должно :-) Сейчас мало кто ориентирован на долгосрочный результат, оттого и обучающие материалы, которые на виду, не затрагивают такие моменты. Может даже есть что-нибудь толково написанное по теме, но им пользуются только матёрые спецы, а отсльные могут и просто не знать.
Один словарь с модификаторами не всегда удобен. Эффекты накладываются из разных мест (экипировка, ауры, способности героя и т.д.), поэтому словарь может быть трудно поддерживать.
У себя в игре я сделал один метод который опрашивает все связанные с юнитом сущности, вызывая что-вроде .modify_value(type, current_value), что и как в итоге будет это значение модифицировать не важно. Плюс автоматическое кэширование всех вызовов этого метода со сбросом при ключевых событиях (вроде смены экипировки).
