Захотелось написать небольшой опус в дополнение поста в начале топика. Данные наблюдения выработаны на основе некоторой практики разработки браузерной игры.
Сначала немного страшилок:
1. Если вы думаете, что разрабатывать игры - это просто и приятно, то вы ошибаетесь. Если вы думаете так о разработке браузерных игр, то вы ошибаетесь вдвойне. Разработка игр - это офигенно сложная штука. Скорей всего - это самый сложный путь который может выбрать для себя программист.
2. Если вы новичок в программировании - лучше пойдите подучитесь. Иначе будет только разочарование. При этом я не имею ввиду обучение конструкциям нового для себя языка программирования. Я имею ввиду обучение программированию как таковому - алгоритмы, парадигмы, паттерны и т.д. Это та база которая позволит впоследствии изучать новые технологии очень быстро. Напишите парочку утилиток для себя, придумайте несколько велосипедов, разработайте собственный арканоид, тетрис, змейку, может еще что-то. К сожалению изучить программирование быстро вряд ли получится. Я бы сказал, что быстрее чем года за три набрать необходимый багаж знаний не выйдет. Хотя всяко бывает. Когда почуствуете, что реально готовы - можете возвращаться.
3. Потянуть самому разработку игры такого класса с вероятностью 99,9% не получиться. Даже если вы уникум и в вас по какому-то недоразумению природы сочетается и программист и художник (что обычно несочетаемо), то у вас банально не хватит времени чтобы завершить игру в обозримый срок. Придется искать людей с которыми можно было бы работать вместе. Найти таких людей кстати та еще задача.
4. Нужно быть реально фанатом своего дела и нереально целеустремленным. Поверте, на старте проекта вы не будете подозревать и о малой доли тех трудностей которые на вас выпадут. Количество граблей на котрые вы наступите трудно будет даже сосчитать. Для того чтобы их пройти нужна недюжинная сила воли и твердый характер. Если вы не готовы работать над проектом с раннего утра до полуночи без выходных и каникул, то толку будет мало.
5. Вам придется вкладывать в разработку проекта свои деньги. Возможно небольшие, но точно придется, при этом длительное время не получая ничего взамен. Это ваши инвестиции которые также являются залогом того, что вы настроены серьезно и твердо идете к цели. В случае с браузерными играми вам не обойтись без затрат на хостинг и оплату домена. Также сюда можно включить затраты на покупку необходимого оборудования (в моем случае это была покупка нового ноута, а также планшетов художникам), оплата как домашнего так и мобильного доступа в Интернет (с кокого-то момента вы не сможете себе позволить роскошь не иметь его) и т.д. В роли офиса, для встреч членов команды, обсуждений и мозговых штурмов, мы используем столик в кафе, что также отражается на расходах. При этом объем неденежных инвестиций, а именно инвестиций вашего свободного времени (например на изучение новой технологии), будет вообще зашкаливать.
6. Очень важно знать английский язык на уровне достаточном хотябы для свободного чтения технической литературы и возможности общаться на тематических форумах. Также желательно уметь воспринимать технический английский на слух, в таком случае вы сможете смотреть онлайн конференции разработчиков или всякие лекции в западных вузах. Без знания языков вы будете находиться в информационном вакууме. Объем технической информации доступной на том же русском языке настолько ничтожно мал по сравнению с ней же на английском, что вы просто можете не знать о существовании многих реально потрясных вещей.
Если вышеописанные пункты вас не испугали - значит вы один из немногих кто способен довести дело до конца. Далее приведу несколько советов:
1. Выясните для себя с какой целью вы занялись разработкой игры. Например - создать коммерчески успешный проект и заработать денег. Цель "just for fun" также возможна, но будет сложнее с мотивацией да и странно разрабатывать мультиплеер (а ведь браузерные игры в большинстве своем именно такие) просто так, ведь хотелось бы чтобы в него играл еще кто-то кроме вас.
2. Определитесь с идеей и концептом игры. Чем подробнее вы все продумаете тем лучше. Старайтесь при этом быть реалистами и трезво оценивать свои силы. Имейте ввиду, что сама идея без реализации - ничто. Миллион умноженный на ноль даст ноль, аналогично даже супер мега идея буде не большим чем бесполезной писаниной если не будет реализована. Вариант "у меня есть мега идея, но я ничего не могу, поэтому хочу набрать программистов и художников которые бы делали то, что я скажу, а я потом поделюсь выручкой" - обречен на провал. На начальном этап ценность любой идеи весьма условна. Если вы делаете коммерческий проект, то представьте себя на месте его рядового пользователя и чесно себе скажите - согласны ли лично вы были бы тратить деньги на него, если да - продолжайте, если нет - у вас не будет достаточно мотивации чтобы завершить свой проект, меняйте концепцию.
3. Вам необходима команда. Желательно чтобы в ней был самый минимум людей реально необходимых для работы. Т.е. например ищите второго художника только в том случае если один реально не справляется с объемом работ. Нужно с самого начала четко со всеми согласовать с какой целью делается проект, обязанности каждого и его долю (или зарплату, если вы нанимаете человека временно) с прибыли. При этом адекватных людей согласных работать за долю в проекте найти очень сложно. Желательно также не искушаться включать в команду друзей если только не уверены в них на 100%. Работа есть работа, но у каждого человека разные о ней представления, лучше просто не ставить себя перед выбором - завалить проект или потерять друзей.
Вам необходимо будет выделить в команде человека, который бы исполнял обязанности менеджера проекта. В разработке таких больших проектов вылазит много рутины, типа обзвонить всех членов команды, согласовать встречу, поставить задачи, проконтролировать исполнение старых, определить причины отставания от графика, перераспределить обязанности в случае какого-то форс-мажора и т.д. Это каторжный труд на самом деле, придется также изучать менеджмент и психологию. Возможно стоит принять за основу одну из стандартных схем разработки, например Scrum. Само-собой нужно назначить для себя конкретные временные этапы разработки, т.е. конкретные даты когда вы собираетесь запускать проект на сервере, когда хотите иметь уже более-менее играбельную альфу, когда начинать тест и т.д. Даты конечно нужно назначать реальные, но и придерживаться их в дальнейшем.
Еще, желательно в самом начале формирования команды продумать разные скользкие моменты. Например как вы будете в случае чего расставаться с каким-либо членом команды? Это очень важный вопрос на самом деле, ведь вы не можете знать наперед как человек будет работать в команде. Многие могут быть прекрасными специалистами сами по себе но не быть командными игроками. Иногда люди могут терять интерес к тому, что вы делаете. Бывает. Но у вас есть цель - сделать успешный проект и поэтому нужно уметь в таком случае вовремя разойтись. Возможно выкупив долю, если член команды внес ощутимый вклад в проект. Совсем неплохо заключить на каком-то этапе что-то вроде договора о намерениях, с юридической точки зрения он не будет иметь силы но усное соглашение изложенное на бумаге и скрепленное подписями играет большую роль. На этом этапе кстати как раз и могут вылезти конфликты, но тут реально лучше раньше чем позже.
4. Определитесь с технологиями. Скорей всего придеться прошерстить Интернет на предмет того кто, что использует и попытаться выяснить плюсы и минусы разных технологий. Совсем неплохо если выясниться, что те технологии которые вы уже знаете можно использовать в вашем проекте, значит учить придется меньше. При этом технологии лучше выбирать с таким расчетом чтобы осязаемый результат можно было увидеть как можно скорее. Готовый прототип, пусть даже жутко глючная пре-альфа с 70% неработающих функций - это то, что должно быть готово как можно скорее. Что-то осязаемое также способно сильно поднять моральный дух команды, долгое же расписывание идеи в надежде когда-то приступить к разработке - способно его безвозвратно уронить. Здесь уже лучше не изобретать велосипеды, а стараться использовать высокоуровневые инструменты и фреймворки. А вот к использованию готовых движков я отношусь скептически, поскольку движок в браузерных играх практически полностью определяет функциональность игры, и если плодить игры на одинаковых движках, то в итоге получится то, что уже есть в рунете - куча клонов почти неотличимых друг от друга.
При этом лучше оставаться в рамках доступных технологий. Если вы видите, что для реализации какого-то второстепенного элемента геймплея вам нужно делать очень серьезные изменения в коде - лучше внесите изменения в концепт. Скорость разработки - важный момент, поскольку время - это тот ресурс которого вам никогда не будет хватать. Поэтому если что-то тормозит вас в работе, то его нужно отбрасывать. Также на начальном этапе важно не забивать себе голову излишней оптимизацией. Преждевременная оптимизация погубила не один проект, важен осязаемый результат как можно скорее, а если будет тормозить, то оптимизировать можно и позже.
Про сами технологии я говорить не буду, их очень много. Для клиента вы можете либо ограничиться обычными возможностями HTML и JavaScript, либо обратить внимание на нововведения в HTML5, можете использовать всякие JavaScript фреймворки, или такие технологии как Flash или Silverlight. На сервере обычно простор больше, можете использовать PHP, Python, Perl, Java, ASP.NET, или даже экзотику вроде Erlang. Это уж как захотите и что выберите. Одно общее - в принципе построения клиент-серверных приложений разбираться придется.
Кроме самого программирования нужно определиться и с сопутствующими технологиями на которых будет держаться процесс разработки. Это система контроля версий, таск-трекер, баг-трекер, вики для написания документации и пр. Иначе вы очень скоро потеряете контроль над своим кодом и над текущим состоянием проекта.
5. Почему я говорю про важность скорости разработки? Дело в том, что ваш проект в изначальной своей задумке может оказаться невостребованным и неинтересным. Это абсолютно будничная ситуация. То, что интересно вам не обязательно интересно другим. Но поверте, чем быстрее вы об этом узнаете тем лучше. Это даст вам лишнее время на переписывание сценария и не даст упасть духом.
6. Имейте ввиду, что после того как ваша игра станет доступна для людей из вне - объем вашей работы только увеличится. Процесс постоянного закрывания багов не так интересен как придумывание игры. Отвечать на письма в саппорт вообще радости мало. Но если вы дотянете до этой рутины, то это уже много значит.
7. И в заключение - бойтесь стереотипов и шаблонов. Они убивают креативность. Выслушивайте чужое мнение но принимайте решение самостоятельно, изучив все факты.
Но я все таки посоветую те книги по которым сам учился: 
