Ещё совсем недавно веб был совсем другой: скрипты хостились на shared-хостингах где набор доступных библиотек жёстко фиксировался хостером, и везде правил PHP.

Огромный зоопарк фреймворков, несовместимых библиотек, некоторые из которых требовали специальных опций в php.ini для своей работы, некоторые работали только под определёнными версиями PHP. В общем прелесть.

С появлением «ООП» в PHP стало лучше, жить стало веселее, люди стали создавать фреймворки соревнуясь с джавистами в обобщённости и абстрактности. В итоге всё это было похоже на огромную несовместимую кучу говна.

Потом что-то изменилось. Возможно потому что VPS вошли в моду и стали повсеместно доступны, может ещё что-то. Так или иначе Ruby on Rails стал набирать популярность.

Думаю никто не станет спорить, что сегодня RoR является наиболее комфортной платформой для веб-разработки:

• Строгое разделение кода по функциональности. MVC во все поля.
• Тесты, тесты, тесты. Множество фреймворков для тестирования, сложившаяся культура в сообществе.
• Гибкое управление пакетами (rubygems & bundler), использование специальных версий библиотек не доставляет боли.
• Огромное количество библиотек, в первую очередь для вебаю

И уже не важно тормозит Ruby или нет (по последним бенчмаркам он сравнялся с Python). Этот недостаток перевешивают преимущества, так необходимые для реальной разработки.

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

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

А теперь взглянем на gamedev

Там сложилась очень похожая ситуация что и недавно в вебе.

Игры принято писать на С++. Это мультипарадигменный язык, на нём можно писать в различных стилях: можно использовать дикую шаблонную магию в стиле boost, можно с любовью городить монструозную иерархию классов, как привыкли джависты, можно вообще писать в сишном стиле, только структуры и функции, только хардкор.

Открывая любой проект написанный на C++ вы не можете знать наверняка с чем вам придётся столкнуться.

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

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

В Rails мире такая проблема решается просто: форк проекта с наложением патча и инструкция в Gemfile с требованием использовать код из нашего репозитория. Всё.

В мире C++ такая информация передаётся из уст в уста, или в файликах README, как в старые добрые времена. Плохо когда нет автоматического управления зависимостями. Очень плохо.

Культура тоже сложилась не ахти какая. Тестировать код (автоматическими тестами) – скорее исключение чем правило. Зато повсюду принято писать микрооптимизации, некоторые умудряются вставлять куски кода на асме, всё потому что “так быстрее работает”, разумеется не подкрепляя утверждения никакими бенчмарками.

Очень похоже на ситуацию что я описывал выше. Разброд и шатание, блядство-разврат-наркотики.

И как сделать лучше?

Ясно что C++ здесь не подходит. Очевидно что это должен быть язык, реализация которого достаточно быстро оперирует с числами, но при этом без багажа C++. Язык достаточно гибкий для создания сложной, расширяемой архитектуры. В идеале это должен быть язык работающий и под iOS и под Android. Правда не уверен возможно ли это.

Мне нравится пророчить Go на это место. Перечитав строки выше понял что JavaScript вроде бы тоже подходит.

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

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

Если подумать, то похоже игровой код может лечь в MVC:

• World/Models – здесь хранится весь мир, игровые объекты, их состояние и характеристики, игровые координаты. Для каждого world определён метод process, который обрабатывает действия в мире с течением времени. Частота обработки фиксируется при подлючении этого world. Также World должен отвечать за обработку физики.

  Большая часть логики кода должна быть записана здесь.

• View – код отвечающий за отрисовку конкретных объектов на экране. Список объектов необходимо запрашивать у world. Шейдерная магия также определяется здесь. У каждого из view должен быть метод draw который вызывается по таймеру.

• Controller – набор обработчиков событий, как внутриигровых, так и устройств ввода, а также обработку пакетов из сети.

К примеру если потребуется сделать игровой сервер, то он мог бы иметь несколько World-ов обрабатываемых одновременно, и не иметь никаких view (и вовсе не иметь видеокарты). Для сервера пришлось бы дописать несколько контроллеров работающих с сетью, но в целом, код тот же что и на клиенте.

Итог: весь пост это моё имхо, я только пробую себя в gamdev, если где спорол херню – кидайте какашки в комментах.