С чего начать разработку игр?

[RunBeaver]

Доброго времени суток.

Увлекся написанием флеш игр. По работе знаком с разработкой, но работаю не программистом. Начал с прочтение и осмыслевание Колина Мука AS3. Как пробу пера написал тетрис. Если кому интересно(что врядли) могу выложить флешку/исходники. Потом был перерыв. Хватался за разные идеи, но ничего больше не довел дальше уровня простой демки.

Собственно вопрос. Есть какие-то классические задачки, для тех кто учится написанию флеш игр?
Что стоит пробывать, а что нет?

Например ммо нет смыла даже хвататься, но вот игру по сети хотелось бы попробывать делать, но пока наверное рано.

Пожалуйста, подскажите вектор развития, а то сам себя путаю, всё хочется, но всё сразу невозможно делать.

П.С. Не представляю что делать с графической состовляющей, рисовать не обучен.

[Vektor]

У меня, всё тоже самое, один в один, наверно мысли мой прочитал. :)
Завтра послезавтра дадут тест, если выполню, буду программировать игры.
Если, не выполню(что вряд ли), всё равно буду делать игры.
Что стоит пробовать, а что нет?
Тут общего ответа нет, что пробовать, а чего не пробовать.
Я накупил, целую кучу литературы, по программированию и про то, как делать игры 2d-3d.
Изучать, Flash+Xml, Flash+Socket, и пробовать делать то что, кажется сложным.
Требование к программистам, чтоб код был модульным, и чистым в написании, чтоб после твоего ухода, куда-нибудь, код не пришлось выкидывать на помойку.
Ну а, в общем, чем больше знаешь, тем лучше спишь.

[goodguy]

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

[RunBeaver]

Vektor,
Приятно знать, что ни у одного меня схожие сложности.
Если не секрет, расскажи о каком тесте ты говоришь?

[Dukobpa3]

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

Можешь рискнуть сделать пару сайтов на фрилансе, поймешь хоть основы работы по сети. Желательно чтоб с админкой или же чтоб сам сайт что-то там мог в базе данных менять, мейлы какие-то отправлял и в таком духе. Только увлекаться не стоит, сайты это всё-таки не игры:)

А дальше уже -
По сложности:
- пошаговый клиент-сервер (карты какие-то например)
- p2p соединение
- риалтайм-онлайн клиент-сервер.

Ну вот как-то так и двигайся.

Но тут тоже, я отсортировал по сложности по техническим параметрам. А есть еще куча. Например для карточной игры будет крайне сложно без опыта баланс просчитать (имеется в виду не какой-то покер а MTG).
Можно сделать какие-то шашки-шахматы. Правила простые, разработка тоже, плюс игра пошаговая. Многое понять получится.

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

Вот как-то так. К чему считаешь себя готовым то и делай.
Ну и так чтоб начать то можно с какого-то клона. Порыскай по порталам флешовым, посмотри что нравится и попробуй повторить.

[goodguy]

Ну с этим совсем уж не соглашусь.
Сколько людей, столько и мнений.
Вот с сайтами на фрилансе это ты перегнул. Процентов 99.99% что новичку там ловить вообще нефиг.
Я лично вообще флеш сайтов не делал. Игры - это игры, а сайты - это сайты. Нужно выбрать что-то одно. Сразу начал с ММО. Смысл как раз в том, что если во что-то серьезно уперся, и после долгих мучений умудрился не бросить это дело, а найти решение проблемы, то чувствуешь в себе силы сделать еще больше.
А клепать разные простенькие клоны чужих игр - это неинтересно. Имхо конечно, но я считаю такой путь более долгим и неправильным.

[-De-]

А выложите таки флешку и исходники.
Для большинства начинать с ММО - самоубийство, да и goodguy ещё не закончил.

[goodguy]

да и goodguy ещё не закончил.
Да, но все, что я знаю о флеше (да и о джаве), я узнавал в процессе разработки этой игры )
Для большинства начинать с ММО - самоубийство
Ну можно не ММО. Придумать однопользовательскую игру, но с кучей возможностей. И пытаться их реализовывать. Главное не клепать разные тетрисы арканоиды аля галактика на денди и морские бои :D
Это слишком банально

[Aquahawk]

Я хоть уже и зарабатываю на жизнь флешом люблю делать так:
Идём на wonderfl (http://wonderfl.net/) и ищем там крутую весч. Пытаемся повторить не читая исходников. И вообще неблюдая за разработками других (конг и прочие порталы) ищем там такие вещи которые вызовут у вас Wow! как они так сделали. И берёте делаете лучше. У меня как правило при достижении полурабочего прототипа уже интерес пропадает, основная проблема к тому моменту решена а опыт и вдохновение остаются со мной.

[RunBeaver]

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

-De-
вот архив http://dl.************/u/3087325/Tetris.zip
вот сама флешка http://dl.************/u/3087325/Tetris.swf

[Dukobpa3]

Насчет исходников.
Вполне грамотно написано всё, даже неохота влазить с советами.

Слегка некошерный МВЦ, например геймвью имеет ссылку на контроллер, хотя там поидее должен быть просто диспатч события в контроллер а контроллер уже сам принимает решения. Вью должна иметь ссылку только на модель.

Вьюхи добавляются прямо на стейдж, что не есть правильно. В большинстве случаев особо не навредит, но так лучше не делать. Как по мне то лучше завести для всех слоев отдельный спрайт-контейнер, или как минимум один (например можно было все вьюхи пихать не на стейдж а в Tetris, он ведь тоже спрайт, и он лежит на стейдже, и это было бы куда правильнее)

Вот как-то так. Я видал исходники и похуже в разы, на фрилансе и не такого порою насмотришься))
А тут всё сравнительно круто) Дерзайте.

[RunBeaver]

Спасибо за хороший отзыв.

Если браться за игру "на двоих" где ходы делаются пошагово, с прочтения чего лучше начать?
Особенно интересует серверная часть. С клиентом более-менее понятно, сокеты надо смотреть.
А вот с сервера - даже не знаю за что хвататься.

[Dukobpa3]

Ну тут я хз на самом деле.
Пошагово можно делать сокетом, можно делать через обычный себе хттп.

Если делать сокетом то чуть сложнее будет сервер.
Через хттп запросы-ответы можно обойтись пачкой скриптов на ПХП.

Смысл таков что есть база данных некая, в ее роли может быть даже папка с файлами хмл или джейсон, это уже по вкусу. Понятное дело что файлы будут работать медленнее нежели тот же MySQL.

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

Ну и с клиентов приходят запросы, сервер на них отвечает. С этим справятся и скрипты.

Сеанс игры с технической точки зрения выглядит примерно так(рассмотрим что-то типа шахмат):
- клиент1 заходит в игру, здоровается с сервером
- сервер получает приветствие, фиксирует факт наличия игрока онлайн, смотрит зарегистрировал ли, и есть ли какие-то стартовые параметры у этого игрока (на первое время лучше историю не вести, просто чтоб вошел и мог поиграть)
- далее клиент1 открывает некое лобби, шлет серверу соответствующий запрос
- сервер получает запрос от клиента показать список игроков онлайн, делает выборку по всем игрокам онлайн которые не в игре на текущий момент, отправляет это клиенту
- клиент1 получает этот список, показывает его. Игрок1 видит этот список, кликает по одному из имен в списке, каким-то образом отправляет приглашение на сервер для клиента2, клиент1 переходит в режим ожидания
- сервер получает от клиента1 приглашение для клиента2, отправляет приглашение клиенту2
- клиент2 получает приглашение, соглашается, шлет на сервер сове согласие, переходит в режим ожидания
- сервер получает согласие от клиента2, пересылает его клиенту1
- клиент1 получает согласие на приглашение, посылает серверу команду начала игры
- сервер получает команду начала игры клиента1 с клиентом2, отправляет обоим стартовые параметры игры(расположение фигур прочее блаблабла), у себя открывает какую-то таблицу в которой фиксирует весь прогресс игры, и по которой производит контроль за обоими клиентами.
- далее клиент1 имеет первый ход, переставляет фигуру с места на место, шлет это серверу, сервер смотрит по своим записям можно ли сделать такой ход, если можно - шлет клиенту2 новые координаты фигуры, если нельзя шлет клиенту1 отказ. Чтоб избежать лишних отказов доп проверка должна быть и на клиенте.
- клиент2 получает новые координаты, меняет отображение, делает ход сам.
- ну и так далее.
- в определенный момент наступает конец игры, сервер по своим записям понимает что один из клиентов выиграл, отправляет обоим клиентам поздравления одному с победой второму с проигрышем, фиксирует где-то этот результат(или не фиксирует как мы выше говорили)
- клиенты получают эти сообщения переходят в статус свободных (не в игре), становятся доступными в лобби, ну и так далее.

Вот как-то так.

Насчет почитать хз. Я не зря сказал что неплохо парочку сайтов сделать. Простенькую визитку можно сделать за день-полтора, но там уже будет знакомство с ПХП скриптами, коннект по сети хоть какой-то. Я с пхп серверами не работал если честно, всегда как-то с питоном, но питон это еще один язык на изучение, может быть не шибко весело для начинающего. А простенький пхп-скрипт уметь сделать любой флешер просто обязан))

Добавлено через 7 минут
- сервер получает от клиента1 приглашение для клиента2, отправляет приглашение клиенту2
Блин, косяк))
Короче без сокета сервер не сможет ничего слать клиентам по своему усмотрению. Он может только отвечать на запросы.
Поэтому отправка чего-либо сервером клиенту в данном случае будет выглядеть как автообновление с неким периодом на клиенте, а сервер просто фиксирует очередь сообщений для него. Автообновление это клиент будет раз в сколько-то секунд слать запрос на сервер "ну что там, есть новости?" А сервер если очередь не пустая отвечает "да, есть, вот держи".

Ну и если ориентироваться на самый простой вариант сервера со скриптами, то логику туда вынести будет проблематично и всякие проверки адекватности ходов. Поэтому придется делать это всё на клиентах.

//***********************
Ну или разбираться с сокет-сервером.
Касательно серверов мой выбор python + MongoDB + Redis. Но это совсем другая тема. И для другого форума.

[RunBeaver]

Очень приятно Ваше желание помочь.
Выбор пайтона мне очень близок. Во-первых есть небольшой опыт. Во-вторых... не буду говорить во-вторых что б не холиварить :-)

Я уже упоминал, что по работе знаком с разработкой. Я работаю тестировщиком. В работе иногда приходится и программить по чуть-чуть, в том числе и на пайтоне логи парсил.
Делать запросами - вообще не вижу смысла. Так как хоть сайты и не писал, а сервисы писал, и как это работает понимаю. Буду разбираться как написать сервер для работы через сокеты. На самом деле с моей стороны не честно просить всё расжевать. Не маленький уже.

Еще раз спасибо. Поддержку и вдохновение получил. Теперь дело за мной.

[Dukobpa3]

Ну если питон не в новинку то ваша дорога в сокет-сервер))

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

[Vektor]

Посмотрел, твой код, по игре тетрис, что можно сказать.
package – разберись с этим.
public - это свойство должно появляется только в исключительных случаях, лучше использовать - internal, переменные если они должны быть видны в другом месте, для этого есть get и set.
Для такой не сильно сложной игры, слишком много классов.
Классы лучше использовать только в тех случаях, когда надо разбить игру на блоки или код настолько универсален, чтоб его не меняя можно вставить в другую игру или приложения.

Да, в блок могут входить несколько классов, но желательно, чтоб эти классы были универсальны, или улучшали читаемость и поддержку кода в будущем.

Блоки - это независимые классы, например, создается игра.
1) Делаем Prealader, блок независимый от того какая игра загружается.
2) Делаем Экран - Начало Игры, здесь игрок может перейти к просмотру рекордов, зарегистрироваться или выбрать своё имя, для новой игры или для загрузки игры, выбрать в какой режим игры играть, если есть такой выбор (здесь нужно создать сохранения и загрузку игроков, которые уже играли в игру или собираются в неё играть).
3) Рекорды – Он считывает результаты, достигнутые в игре, и отображает их на экране.
4) Сама игра – Здесь тоже, можно и нужно разбивать игру на классы, например класс - инвентарь , это отдельный блок, в котором персонаж может менять экипировку, рыться в рюкзаке и так далее, класс - магазин, класс - монстр, класс - ещё чего ни будь, главное не путать Блок-Класс, Класс-функция, и ещё ООП дело хорошее и нужное, но только если, игра большая, или код будет использоваться в продолжении игры, или в поддержке игры долгое время, типа онлайновых игр.

Ещё, вот о такого надо избавляться, при добавлении нового правила в игру, весь код надо будет, полностью перелопачивать, явно не правильно составлена логика кода.
var collisionWithOtherObject:Boolean = _model.glass.blocksCont.hitTestPoint(bl.x + _model.figure.x + block.bl_size/2 + block.bl_size * direction,
bl.y + _model.figure.y + block.bl_size/2, true);
if (collisionWithOtherObject ||
bl.x + _model.figure.x == _model.glass.x && direction == -1 ||
bl.x + _model.figure.x + block.bl_size == _model.glass.x + block.bl_size*_model.glass.width_bl && direction == 1) {
collision=true;
}
Удачи, в учебе и труде на поприще, разработки игр.