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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё, вот о такого надо избавляться, при добавлении нового правила в игру, весь код надо будет, полностью перелопачивать, явно не правильно составлена логика кода.
Удачи, в учебе и труде на поприще, разработки игр.