1. Изучать документацию по GCC (раз используеш DevC++, то как раз используеш MinGW, что является виндовым портом GCC). Разбираемся с нуля в том, что такое компилятор и линковщик, и вообще всю теорию о том как из исходников собирается бинарник:
http://www.network-theory.co.uk/docs/gccintro/index.html
2. Берем книгу Кернигана и Риччи о языке C, делаем тамошние упражнения пока не придет понимание особенностей чистого C лежащего в основе C++
http://cgip.inf.unideb.hu/eng/rtornai/Kernighan_Ritchie_Language_C.pdf
3. Штудируем уже сам C++. Впринципе названия книг выше приводились, но в интернете также всяких ресурсов до фига.
4. Паралельно проникаемся идеями объектно-ориентированного программирования. Неплохая книга - Айра Пол. Объектно-ориентированное программирование на C++. Выучить просто синтаксис описания класов - это все до одного места, ООП - это отдельная философия которую нужно понять (реализация ООП в C++ - это только один из вариантов, в других языках часто используются другие реализации, поэтому важно уловить саму идею).

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

Данные наблюдения выработаны на основе некоторой практики разработки браузерной игры.

Сначала немного страшилок:

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. И в заключение - бойтесь стереотипов и шаблонов. Они убивают креативность. Выслушивайте чужое мнение но принимайте решение самостоятельно, изучив все факты.

Оранжевая иконка в нижнем правом углу - это активная спецспособность. После ее активации карта пропускает один ход. Также существо выложенное на поле боя всегда пропускает первый ход, атакует только со следующего.

За один ход можно либо выложить одно существо либо вызвать одно заклинание. Допускается выложить существо, а потом еще произнести заклинание, но не наоборот. Спецспособность можно активировать за один ход одновременно у разных существ, но у каждого конкретного существа не больше одного раза. Позже в игре появятся артефакты (сейчас можно видеть только пустые слоты под них) которые также будут влиять на бой. На ход отводится не больше 2 минут, сколько осталось можно видеть слева на таймере. Если время истекает, то атака будет инициирована автоматически.

Теперь вроде все.

Можете кстати поэкспериментировать с разными браузерами. По идее в Google Chrome игра должна работать шустрее, поскольку у него очень быстрый движок JavaScript. Если используете Firefox, то просмотрите какие плагины у вас установлены, возможно какой-то из них влияет на работу игры. Ну и быстрое подключение к Интернету также желательно. Хотя клиент обменивается с сервером довольно малыми пакетами данных, основная нагрузка - это подгрузка картинок. Но тут также есть способы как ускориться.

Вот вам еще ссылка на книгу Кернигана и Риччи (кстати это автор языка C который лежит в основе C++) C Programming Language: http://net.pku.edu.cn/~course/cs101/2008/resource/The_C_Programming_Language.pdf
Откройте там 5-ю главу и почитайте про указатели и массивы, может перестанете удивляться.

Вот еще обсуждение данной особенности массивов на StackOverflow: http://stackoverflow.com/questions/381542/in-c-arrays-why-is-this-true-a5-5a
Можете еще по ходу изучить интересный тред там же о малоизвестных особенностях языков программирования: http://stackoverflow.com/questions/1995113/ Думаю узнаете много нового.

1. На практике, процент задач требующих жуткой оптимизации по скорости выполнения очень мал. Вообще скорость выполнения большинства задач не является критическим фактором. В самом деле, конечному юзеру глубоко наплевать на то, выполняется задача за 0,1 секунды или за 0,01 секунды. Кроме того большая часть программистов врядли способна соревноваться в написании оптимального кода с современными компиляторами. Поверте, написать медленный код на Ассемблере намного легче чем на C# или даже Python.
2. Зато есть другой важный фактор - скорость разработки. Сегодняшний рынок IT (не только разработки игр, а вообще) очень динамичен и если вы потратите лишнее время на разработку, то пропустите вперед конкурента, и как итог - потеряете деньги. Конечно же скорость разработки на C# будет в несколько раз выше чем на C++ и просто глупо этим не пользоваться. Причем скорость в том числе обеспечивается и меньшими затратами на отладку, поскольку допустить ошибку в коде на C++ несоизмеримо проще, а найти сложнее. Кроме того, программирование на относительно низкоуровневых языках, как тот же C++, порождает проблему преждевременной оптимизации. В свое время еще Дональд Кнут писал, что преждевременная оптимизация - зло. Вместо того чтобы сосредоточиться на задаче и решать ее, программист занимается оптимизацией какого-то блока программы не влияющего напрямую на решение задачи. В итоге разработка затягивается, а на выходе мы не получаем не то, что быстрого кода, а даже и хоть как-то работающего.
3. .NET так же как и Java, и некоторые другие подобные платформы поддерживает JIT. Т.е. при первом запуске ваш код автоматически компилируется в машинный код конкретной платформы, и при следующих запусках будет уже запускаться он. В такой ситуации разница в скорости между программой написанной на C++ и программой на C# может быть вообще мизерной. Что касается разнообразных тестов, то их можно накопать сколько угодно с разных сторон, но они все синтетические, в реальной жизни задачи более разнообразны.
4. Ручное управление памяти в C++ чем многие так гордятся, на практике порождает только проблемы, поскольку вместо решение конкретной задачи программист занимается борьбой с компилятором и устранением утечек памяти. Современные языки со сборщиком мусора этой проблемы не имеют, поскольку умеют освобождать память автоматически.
5. Тот же .NET вполне себе позволяет при желании использовать библиотеки написанные на обычном C++, поэтому если уж так нужно что-то оптимизировать, то флаг в руки.
6. Большая проблема .NET - отсутствие полноценной кросплатформенности. Впрочем, есть Mono, так, что сейчас на C# можно вполне нормально писать и под Linux.

Все это не означает, что C++ плох. Нет. У него все еще есть своя ниша которую он успешно занимает. Но извините меня, каждый инструмент хорош к месту. А C++ и C#, как и другие языки - это всего лишь инструменты, и ничего более. Именно по этому часто просто глупо стараться использовать для всего проекта один и тот же язык. Пишите на том, что повысокоуровней и попроще. Проверяете, тестируете, вылавливаете медленные места. Если скорость где-то вас не устраивает, то локализуете такие места и выносите их во внешние библиотеки которые можно написать на том же C++, а может и чистого C хватит. Во всех остальных случаях, применение низкоуровневых инструментов - это трата пустая времени.

Не знаю почему, но иногда многие преподносят C++ как супернавороченный язык со сверхвозможностями, почти как панацею от всего. Извините, но выглядит со стороны это не более чем желание показать у кого длиннее. Тем более, что многие C++ программисты свой язык понимают откровенно слабо. У некоторых наступает просто разрыв шаблона когда они узнают, что в C++ записи a[10] и 10[a] являются полностью эквивалентными. Некоторых воспитанных на современных IDE (как тот же VS например) ставят в тупик вопросы по написанию make-файлов. А все это вещи которые дают понимание языка. Если вы считаете, что знать C++ это круто, то это нифига не так. C++ это давно уже обычно, привычно и банально. Если же считать показателем крутости сложность языка для среднестатистического программиста, то любой программист на Lisp, Erlang или Haskell должен по идее смотреть на C++ программистов как на говно.

Хотите что-то выбрать? Бросьте монетку, что выпадет то и учите. И то и другое для выбранных задач подходит.

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