Простейший сервер на ASP.NET (C#) для Flash-игр и их связка

Привет всем мастерам отечественного игростроя и не только.

В этой небольшой статье я хочу рассказать о том, как я делал, делаю и возможно буду делать серверы для своих игр в связке Flash AS3 + Windows Server + ASP.NET (C#) + MSSQL Server. Ничего нового или уникального в этой статье нет. Это один из десятков вариантов как быстро сделать серверную часть и связку с ней для клиента. Применяю описанный метод в многопользовательских социальных играх (и приложениях). Но, осмелюсь предположить, что и в однопользовательских играх это вполне применимо, особенно когда речь идет о сохранении профиля на сервере и/или сборе всяческой статистики.

Кому может быть полезна статья?

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

Какие преимущества этого подхода по сравнению с другими?

У описанного подхода, основное преимущество – это его адская простота. Он совершенно не требует углубленного знания языка и серверных технологий, но я думаю, что с быдлокодерством он не имеет много общего. Развернуть такой сервер вопрос 10 минут (при наличии готового «шаблона»). А самое главное, на мой взгляд – такой подход не отвлекает от самого вкусного в игрострое, а именно от создания самой игры. Вполне возможно, что кто-то из новичков захочет использовать его в своих проектах.

И так, что нам нужно:

1. Сервер: любой web сервер на базе Windows с настроенным IIS.
2. Visual Studio: на ваш выбор, но я делаю примеры в 2010, хотя и четверти ее прелестей не использую.
3. Среда разработки Flash AS3 приложений: любая ваша любимая.

Для новичков порекомендую небольшую статью по настройке IIS под Windows Server 2009 R2.

Начнем?

Для связи клиента с сервером я выбрал простейший метод HTTP запросов, в ответ на которые сервер генерирует JSON. Почему не XML? А мне он не нравится неудобочитаемостью и громоздкостью, но это вообще не принципиально, важно, что HTTP.

Схема всей связки:

Примерный сценарий работы клиента:

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

http://{адрес_вашего_сервера}[/{путь_до _приложения}]/{название_обработчика}.aspx[?{какие-то_параметры]}

Сразу оговорюсь, оставлять возможность посылать параметры в GET, вроде как, считается дурным тоном, но для отладки это очень удобно. Поэтому, если будете использовать нечто подобное в релизе, просто добавьте фильтр на сервере на обработку только POST запросов (ниже в описании сервера, я покажу как). A уж на флеше отправить POST запрос тоже самое что и GET, отличие только в этом:

myURLRequest.method = URLRequestMethod.POST;
myURLRequest.method = URLRequestMethod.GET;

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

Хм, надо бы оживить примером:
31.186.99.154/oligarh/gp.aspx?action=getFullUserProfile&nid=1&uid=12787999

Что мы тут видим кроме адреса и названия .aspx страницы для обработки запросов? Правильно, параметры:

action=getFullUserProfile – в этом параметре указано какую ф-ию сервера хотим вызвать и собственно какие данные получить.
nid=1 – в этом указываем в какой социалке запущено приложение.
uid=12787999 – а тут ID этого пользователя данные которого запрашиваем.

А что же мы получаем в ответ? А вы вставьте вышеуказанный урл в адресную строку браузера, нажмите enter и увидите нечто похожее на это:

{
    "error":0,
    "st":"28.03.2012 15:51:09",
    "userInfo":{
        "id":"12787999",
        "level":5,
        "experience":303,
        "bluff":15,
        "money":"-20",
        "vouchers":3,
        "lastVisit":"09.03.2012 10:46:11",
        "booster":{
            "type":1,
            "npd":"",
            "time":0
        }
    },
    "userBusiness":[
        {
            "id":712488,
            "businessID":2,
            "level":1,
            "state":2,
            "npd":"23.01.2012 10:58:51",
            "time":-5633528,
            "eProfits":1,
            "vouchers":0
        }
    ],
    "userBluffs":[
        1
    ],
}

Теперь клиенту осталось лишь применить эти данные и все готово.
Ну да, конечно надо все это обработать как-то … а как?
Слегка подумав, я остановился на 2-х маленьких классах: DataAccessor и DataProvider.
Полагаю, DataAccessor стоит разобрать по полочкам, а в DataProvider-е просто посмотрим логику.

DataAccessor

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

package api
{
  import api.DataProvider;
  import flash.events.Event;
  import flash.utils.getTimer;
  
  public class DataAccessor extends Object
  {
    //DataAccessor не умеет запрашивать данные напрямую у сервера, и поэтому
    //активно использует возможности DataProvider-а
    private var server: DataProvider;
    
    //Тут храним постоянно урл нашего шлюза
    private var m_serverURL: String;
    
    //Тут храним постоянно id нашей социалки
    private var m_netID: int;
    
    //Тут храним все полученные от нашего сервера данные
    private var m_data: Object;
    
    public function DataAccessor ( serverURL: String, netID: int )
    {
      //При вызове конструктора передаем ему урл нашего сервера и id социалки
      m_serverURL = serverURL;
      m_netID = netID;
      server = new DataProvider ( serverURL );
    }
    
    public function get serverURL (): String
    {
      //Нужно на случай если мы захотим в приложении узнать где наш сервер
      return m_serverURL;
    }
    
    public function get data (): Object
    {
      //Часто используется, при любой попытке прочитать полученные данные из приложения
      return m_data;
    }
    
    private function applyNewData ( dp: DataProvider, onRequestCompleteListener: Function = null ): void
    {
      //В этой ф-ии мы проверяем что нам отдал DataProvider, вызываем ф-ию применения новых данных,
      //и оповещаем всех кто просил об этом.
      //Но для начала проверим чтобы data не были null
      //мне было удобно таким образом проверять получали ли мы хоть раз данные или нет
      if ( m_data == null )
        m_data = new Object ();

      if ( dp.errorText != "" )
      {
        //Если в DataProvider-е была ошибока какая-то (в 99,99% это timeout, поэтому можно тут
        //проверить этот факт и повторить запрос, но мне пока такое не требовалось)
        if ( onRequestCompleteListener )
          //Если при вызове ф-ии DataAccessor-а напередавали callback то вызываем ее и передаем
          //объект с ошибкой -1 ("-N" - внутренние, "N" - серверные, "0" - все нормально)
          onRequestCompleteListener ( { error: -1, errorText: dp.errorText } );
        return;
      }
      if ( dp.resultObject.error != 0 )
      {
        //Если в DataProvider-е не было ошибок
        if ( onRequestCompleteListener )
          //Опять же вызываем callback если он был и передаем ему полученные данные
          onRequestCompleteListener ( dp.resultObject );
        return;
      }
      
      var changeArray: Array = syncNewData ( dp.resultObject );
      
      if ( changeArray.length > 0 )
        //если в данных произошли изменения то мы должны оповестить всех подписчиков
        dispatchEvent ( new SyncEvent ( SyncEvent.SYNC, false, false, changeArray ) );
      
      if ( onRequestCompleteListener )
        //Опять же вызываем callback если он был и передаем ему полученные данные
        onRequestCompleteListener ( dp.resultObject );
    }
    
    private function syncNewData ( newData: Object ): Array
    {
      //В этой ф-ии мы применяем новые данные и генерим массив с путями изменившихся данных
      //Но в текущей версии генерация путей не доработана, и мы априори считаем, что данные
      //в ветке поменялись если таковые вообще пришли
      var changeArray: Array = new Array ();
      for ( var item: String in newData )
      {
        if ( m_data [ item ] != newData [ item ] )
        {
          m_data [ item ] = newData [ item ];
          changeArray.push ( item );
        }
      }
      return changeArray;
    }

    public function getFullUserProfile ( userID: String, fromID, onRequestCompleteListener: Function ): Boolean
    {
      //А это как раз пример API ф-ии для получения данных через наш DataAccessor
      //Таких ф-ий может быть сколько угодно много, например: getSomeUserData, setSomeUserData, checkSomeData...
      //Для того чтобы запросить данные создаем новый DataProvider
      var dp: DataProvider = new DataProvider ( m_serverURL );
      //Далее просим его принять наш запрос и в результате получаем Boolean (принял наш запрос DataProvider или нет)
      return dp.execFunction
      (
        //Имя ф-ии на сервере (параметр action в HTTP запросе)
        "getFullUserProfile",
        //Все остальные параметры необходимые для выполнения ф-ии на сервере
        new Array ( { name: "nid", value: m_netID }, { name: "uid", value: userID } ),
        //В этом месте, наверняка, многие захотят меня пнуть кованым сапогом по какому-нибудь чувствительному месту,
        //но я очень торопился когда это писал и анонимная ф-ия мне довольно хорошо помогла.
        //А что собственно тут делается?
        //А всего навсего передается в DataProvider callback функция (к тому же с параметром Event),
        //которая вызывается при завершении работы провайдера и в свою очередь вызывает applyNewData
        //Этот косяк произошел в следствии переделки DataAccessor-а, а DataProvider остался старый,
        //все как всегда уперлось в отсутствие свободного времени, а потом и желания
        function ( e: Event ) { applyNewData ( e.target as DataProvider, onRequestCompleteListener ); } 
      );
    }
  }
}

Как вы уже догадались специфичная часть представлена одной функцией getFullUserProfile, а все остальное относится к служебной.

DataProvider

В этом классе реализована следующая логика:

• формирования строки запроса с параметрами (можно и POST и GET)
• отправка запроса и ожидание ответа с возможностью отсечения по таймауту
• возврат полученных данных подписчикам (в нашем случае DataAccessor)

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

Пора бы нам на сервер заглянуть

Сервер выглядет не сложнее, приведенных выше, двух AS3 классов.
Состоит он в нашем примере из одной aspx страницы gate.aspx и пары классов для обработки данных.
Так как писать полностью рабочий код с БД мне показалось довольно хлопотно для маленькой статьи, я прописал возвращаемый результат прямо в коде.

Рассмотрим каждый файл проекта ближе.

gate.aspx

Это как раз та самая страница aspx, которая принимает запросы от клиента и передает их обработчику нашего API. Смотрим содержимое:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="gate.aspx.cs" Inherits="SimpleGameServer.gate" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<%
    try
    {
        //Очищаем полностью формируемый ответ, т.к. в ответе должна быть чистая строка с JSON
        Response.Clear();

        //Тут мы можем отбрить GET запросы
        //if(Context.Request.RequestType != "POST")
            //return;

        //Создаем наш API обработчик
        SimpleGameServer.API api = new SimpleGameServer.API(Context.Request.Params);
        try
        {
            try
            {
                //Пробуем заставить его обработать запрос и вывести ответ в виде JSON
                Response.Write(api.MakeResponse());                
            }
            catch (Exception e)
            {
                //Ошибка при обработке, покажем ее клиенту, пусть репу чешет чего там не так
                Response.Write(api.MakeError(2, e.Message));                
            }                
        }
        finally
        {
            //Все что надо закрываем и уничтожаем 
            api.Dispose();
        }   
    }
    catch (Exception e)
    {
        //Какой-то глобальный трындец, выложил неотлаженный сервер или залилось с ошибками или чего-нибудь еще
        Response.Write(SimpleGameServer.API.MakeGeneralError(1, e.Message));
    }
%>

Похоже что тут все очень просто. Идем дальше.

API.cs

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

using System;
using System.Collections.Generic;
using System.Collections.Specialized;

namespace SimpleGameServer
{
    public class API
    {
        //Тут у нас записано какие параметры мы вообще будем обрабатывать. Это необязательно, но часто полезно. 
        private string[] serveParams = {"action", "uid", "nid", "m", "some1", "some2", "someN"};
        //В этой переменной мы храним текущее действие, которое должны сделать
        private string action;
        //А тут параметры для действия
        private NameValueCollection parameters;

        public API(NameValueCollection rawParams)
        {
            //Сразу же обрабатываем параметры
            InitParameters(rawParams);
        }

        private void InitParameters(NameValueCollection rawParams)
        {
            //Сразу же запоминаем action
            action = rawParams["action"];
            //Заполняем параметры
            parameters = new NameValueCollection();
            foreach (string paramName in serveParams)
            {
                if (rawParams[paramName] != null)
                    parameters.Add(paramName, rawParams[paramName]);
            }
            //Конечно это только демонстрация, и тут можно делать что угодно с параметрами,
            //например, проверить их на попытки SQL-инъекций
        }

        public string MakeResponse()
        {
            //Вызывается напрямую из gate.aspx
            //Проверяем, что нас просят и собственно пробуем сделать
            switch (action)
            {
                case "getGameInfo":
                    return GameRequestProcessor.GetGameInfo(Convert.ToInt32(parameters["nid"]));
                case "getUserInfo":
                    return GameRequestProcessor.GetUserInfo(Convert.ToInt32(parameters["nid"]), Convert.ToInt64(parameters["uid"]));
                case "addUserMoney":
                    return GameRequestProcessor.AddUserMoney(Convert.ToInt32(parameters["nid"]), Convert.ToInt64(parameters["uid"]), Convert.ToInt32(parameters["m"]));
                default:
                    return MakeError(3, "Че за лажа? Забыл какие я запросы могу обрабатывать?");
            }
            //У меня в одной игре тут очень большой switch, да еще и вложенный, чтобы можно
            //было обрабатывать action вида game.getInfo, user.getInfo
            //Заметьте, что данные тут конвертируются в требуемый тип, но это тоже не обязательно,
            //можно все в string оставить, и отложить проверку типов дальнейшим частям сервера
            //все зависит от того что вы захотите получить.
        }

        public static string MakeGeneralError(int code, string message)
        {
            //Тут мы просто показываем JSON с ошибкой
            //Заметьте, что тут используется JSON.GetJSONStringFromDictionary
            //Что совсем не  обязательно, и проще было бы сделать через string.Format
            var result = new Dictionary<string, object> { { "error", code }, { "message", message } };
            return JSON.GetJSONStringFromDictionary(result);
        }

        public string MakeError(int code, string message)
        {
            //Тут мы просто показываем JSON с ошибкой и текущий action
            var result = new Dictionary<string, object> {{"error", code}, {"action", action}, {"message", message}};
            return JSON.GetJSONStringFromDictionary(result);
        }

        public void Dispose()
        {
            //Тут прописываем все что надо завершить как-то по особенному
        }
    }
}

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

GameRequestProcessor.cs

А вот это сомое главное в нашей гипотетической игре.
В этом классе содержаться всего лишь примеры для 3-х ф-й, которые должны выполнять манипуляции с данными в БД или ФС или еще где-то, а в конце выдать результат который вы должны получить согласно заложенной вами же логике.
Повторюсь, это просто пример, он даже к БД не обращается, просто показывает статические данные.
Смотрим код:

using System;

namespace SimpleGameServer
{
    public class GameRequestProcessor
    {
        //Тут я добавил константу для ошибки, но обычно их может быть оч много, и лучше их вынести в отдельный класс.
        private static string Error_WrongParams = "Один из указанных параметров выходит за границы допустимых значений. Че куришь? Поделись!!!";

        public static string GetGameInfo(int nid)
        {
            //Судя по названию данная ф-я должна выбрать из БД или ФС информацию об игровых объектах и настройках
            //Заодно тут показано что следует предварительно проверить параметры
            //В реальной игре такой статики конечно не сделать ... уж очень много данных может быть
            if (nid > 0 && nid < 5)
                return "{\"error\":0,\"gameInfo\":{\"goods\":[{\"id\":0,\"name\":\"name1\",\"price\":100},{\"id\":0,\"name\":\"name2\",\"price\":200},{\"id\":2,\"name\":\"name3\",\"price\":300}]}}";
            throw new Exception(Error_WrongParams);
        }

        public static string GetUserInfo(int nid, Int64 uid)
        {
            //Эта ф-я должна выбрать из БД или ФС информацию об игроке по его id
            if (nid > 0 && nid < 5 && uid > 0)
                return string.Format("{{\"error\":0,\"userInfo\":{{\"id\":\"{0}\",\"level\":7,\"exp\":99,\"money\":999}}}}", uid);
            throw new Exception(Error_WrongParams);
        }

        public static string AddUserMoney(int nid, Int64 uid, int money)
        {
            //А эта ф-я просто ради шутки :-), добавляет игроку денег ... всегда хотел что-то подобное в нашей жизни найти ...
            if (nid > 0 && nid < 5 && uid > 0 && money > 0)
                return string.Format("{{\"error\":0,\"userInfo\":{{\"id\":\"{0}\",\"level\":7,\"exp\":99,\"money\":{1}}}}}", uid, 999 + money);
            throw new Exception(Error_WrongParams);
        }
    }
}

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

Как подключить БД?

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

• Для начала необходимо создать БД на каком-нибудь сервере, создать пользователя, выдать ему необходимые права на вашу БД.
• Любым привычным способом для вас залить в БД данные, я пользуюсь SQL Server Managment studio.
• Далее в файл Web.config вашего проекта необходимо добавить ConnectionString для вашей БД, например такая:
  

  <connectionStrings>
          <add name="SomeConnectionString" connectionString="Data Source=.\SQLEXPRESS;Persist Security Info=True;User ID=bdusername;Password=userpassword" providerName="System.Data.SqlClient"/>
  

  
  

Вот собственно и все, далее где вам необходимо создаете SqlConnection, потом SqlCommand и выполняете ее получая какие-то данные в ответ, переводите их в JSON.
За последним абзацем, конечно много чего скрывается, и не самого простого, например составление запросов, обработка полученных данных, формирование структуры для экспорта в JSON и много чего еще не лежащее на поверхности. Поэтому пока что осмелюсь предложить поизучать поглубже .NET и SQL, а я в свою очередь, если конечно это будет интересно хотябы нескольким тут живущим игроделам, напишу простые примеры как можно легко и быстро научиться общаться с MSSQL.

Исходники

dl.dropbox.com/u/6005934/fgb/sources.rar

PS:

Выражаю свою благодарность игроделу WeslomPo, за приглашение на FGB и помощь в составлении статьи.

UPD1:

(коментировать не получается, помещаю ответ на первый комент тут)
Да, на Java тоже все хотел попробовать, но как-то руки не дошли пока.
Фиксировал максимальные нагрузки порядка 1000 игровых запросов в секунду + запросы картинок, звуков, модулей игры и т.д., причем это явно не никак не напрягало сервер (были и больше нагрузки, но документально не зафиксировали… т.к. сервер спокойно все переваривал). Основная проблема была в качестве канала… когда подключили 100Мбит/сек выделенный, стало проще. Обобщая вышесказанное — IIS очень достойно все это переваривает, и я пока не увидел какого-то непреодолимого предела для нее в рамках игр для социалок.
Более узким местом была, конечно же, БД. Именно она требовала и требует внимания больше всех остальных. Поэтому количество и качество дисков приходится держать на уровне (2-4 на одну популярную игру, разделяя статические данные, и файлы БД по дискам в зависимости от нагрузок). В дополнение скажу, что одна игра, конечно же, сразу работает на 2-4 социалки, поэтому нюансов много по распределению ресурсов, и особенно удобно смотреть чего куда перенести в моменты массированной рекламы.
По реализации логики, возможно отдельной статьей можно рассказать, там тоже много интересного, но опять же, так как я стартовал первую свою игру не зная кто и как это делает, выбрал для себя наиболее знакомый способ — большую часть логики постарался реализовать простейшими однопроходными запросами, и старался хранить их в процедурах и ф-иях (тут мне, конечно, очень не хватало возможностей из Oracle (Возможно как-нибудь применю его, если не перейду на реализацию логики в отдельном вин-сервисе)). Надо сказать, что возможно мой подход устарел. Отчасти, делаю эту статью, я хотел услышать в коментах об альтернативах, чтобы как-то в современную струю влиться.
Т.к. вся логика в SQL, то основной мониторинг сводится к отслеживанию скорости выполнения запросов и их эффективности. Ну и логи IIS помогают распознать ряд неприятностей. Все это делается в пиковые моменты, которые, чаще всего, запланированы.